Trace the human-agent-tool identity chain

System and boundaries

Start with roles, not one synthetic "agent identity."

• The human or originating service states a goal and can delegate bounded authority.
• The host application manages the conversation, local session, tool set, and model context.
• The model or planner proposes actions. It is not the authority source.
• The MCP client or other connector calls a server.
• The server authenticates the caller and owns published tools.
• The tool implementation validates arguments and acts on a downstream resource.
• A credential broker can hold user or service credentials outside model context.
• The target application owns the final object and action permission.
• The evidence system connects intent, decisions, calls, effects, and revocation.

Each boundary can have a different subject and actor. Preserve both.

Request and decision flow

1. Authenticate the human to the host application. Establish tenant and local session.
2. Create a task identifier and record the requested objective, allowed resource class, impact limit, and expiry.
3. Select a small tool set. Do not let retrieved content expand it.
4. The agent proposes a concrete tool, resource, action, and arguments.
5. Deterministic policy evaluates current human subject, agent or host actor, tool, target, action, context, task, and consent.
6. For high-impact work, an approval component shows the exact normalized action and receives an independent decision.
7. A credential broker selects a credential for the intended issuer, audience, user, route, and tool without exposing it to the model.
8. The tool server validates caller, message, schema, semantic arguments, and resource permission. It invokes the target.
9. The target validates the credential and performs local authorization.
10. Evidence correlates each allow, deny, credential use, tool result, and final effect.

The model's plan can inform the request. It cannot grant the authority needed to approve it.

Failure domains

• The host uses one shared administrator credential for all users.
• A model-generated statement of intent is trusted as policy input.
• The server authenticates the host but loses the human subject.
• A delegated token is passed to an unintended tool or downstream audience.
• One user's tool or credential cache appears in another user's task.
• The approval shows a friendly summary while hidden arguments name another target.
• A tool validates schema but not tenant, path, command, amount, or current state.
• The target accepts a gateway allow as object permission.
• Logs capture the tool call but not the resulting external action.

Test each boundary with mismatched human, tenant, tool, audience, task, and target values.

Design tradeoffs and residual risk

End-user delegation preserves intent and enables user-specific authorization. It adds consent, token lifecycle, and downstream support. Service-owned authority simplifies integration and can become a broad confused deputy. Central credential brokers reduce exposure and increase their own blast radius.

Rich evidence improves accountability and can expose prompts, personal data, and secrets. Record identifiers and normalized security facts. Keep sensitive content only when the investigation need and access policy justify it.

Residual risk includes compromised hosts, valid users requesting harmful actions, goal hijack after approval, downstream over-permission, and completed actions before revocation.

Pomerium boundary

Pomerium can authenticate users, protect MCP routes, apply route policy, and manage documented upstream OAuth connections per user and route. It does not replace tool-level semantic validation or downstream object authorization. Agent hosts and tool servers must preserve the subject and actor needed for those decisions.

Exercise

Trace one real action such as "create issue ENG-482 in project Security." Record the human subject, host, agent instance, task, MCP client, server, tool, normalized arguments, downstream credential audience, resource, action, approval, decision, result, and evidence identifiers.

Run wrong-user cache, wrong-project, wrong-audience, expired-task, changed-argument-after-approval, and direct-tool-server tests. Each must deny before the downstream effect.

Evaluation checklist

• Are human subject, current actor, agent, client, server, tool, and target distinct?
• Does authority remain bound to one task, audience, resource, action, and time?
• Is high-impact approval independent of the model and attached to normalized arguments?
• Does the target still authorize its own object and action?
• Can one evidence chain show who caused what effect without storing a credential?