Identity and agents

One tool call can involve several identities. Amelfi keeps them separate so policy and audit can explain whose authority was used.

Identify each participant

Participant	Question it answers
Authenticated actor	Who presented verified credentials to the gateway?
Agent	Which registered application or automation is acting?
Agent instance	Which execution of that agent is involved, when supplied?
Human delegator	Which person delegated the task, when applicable?
Upstream identity	Which account does the target service see?

An MCP client is the software carrying the request. Its name alone is not proof of an agent identity. Production identity must come from the configured verification boundary, such as signed claims, rather than an arbitrary client header.

Administration and tool use have different permissions

Administrative roles control changes to gateway configuration. Runtime policy controls tool access. An administrator who can register a server has not thereby demonstrated that an agent can call it.

Use authentication to verify administrative identity. Use a governed call to verify runtime authorization.

Choose the credential model deliberately

A service account can serve a shared integration. Delegated OAuth can represent a user. An agent-scoped binding limits an automation to an approved credential relationship. The configured mode must agree with policy and the target resource.

Read agent-scoped credentials before configuring an autonomous workflow.

Implementation reference

Read the source contract.