Module 4 • Lesson 1545 mins

Agent Identity, Elicitation & Multi-Layer Authentication

Separating human authority from agent identity, Just-In-Time approval gates, elicitation payloads, MFA step-up, and Vibe Diff verification.

Grant independent agent identities rather than inheriting user credentials
Design elicitation flows ensuring informed human approvals
Apply MFA and Vibe Diff reviews for consequential actions

Give the agent an identity, not the user's ambient power

An over-privileged agent can become a confused deputy. A malicious instruction asks it to perform an action that its user could technically perform but did not intend. If the agent inherits a long-lived human credential, the system has no clean way to distinguish user behavior from delegated machine behavior.

Separate the human's authority from the agent's identity

Distinguish delegated identity from agentic identity. Delegated identity says which human initiated the task and which user entitlements may be considered. Agentic identity says which non-human actor actually planned or executed the action. The audit record needs both. If the agent runs only as the user, a compromised agent looks like legitimate user activity; if it runs only as itself, the system loses the consent and tenant boundary of the user.

For example, Maya may be allowed to edit every account owned by her sales team. The research agent does not need all of Maya's authority merely because she launched it. For the task "draft a briefing for Acme," it should receive its own identity and a token that can read only Acme's approved fields for a few minutes. The audit record now says both "Maya delegated this task" and "research-agent-v3 made this tool call."

This produces a practical zero-trust identity pattern:

  1. Zero Ambient Authority: the agent starts with no global key and no inherited human session.
  2. Delegated identity: every action remains attributable to the human-agent-task combination.
  3. Just-In-Time (JIT) access: after the exact action is known, issue the narrow token needed for that action and no more.
  4. Resource downscoping: restrict APIs, records, files, environment, and outbound destinations-not just the tool name.
  5. Expiry and revocation: end authority when the step or approval window ends, even if the user's login session continues.

JIT downscoping must reach the filesystem as well as APIs. Use deny-by-default file-tree rules so a generated script can touch only approved project paths and cannot read secrets, deployment manifests, or unrelated build scripts. A child agent or sandbox receives a fresh token for its exact resource and never inherits the parent agent's broader token.