← AI Agent Security Engineering: Prompt Injection, Identity, MCP, and Tool ControlsSkip to lesson ↓

Module 2: Bind Identity, Tools, and Data

Give the Agent Its Own Identity and a Smaller Grant

Separate the customer, employee, application, agent instance, credential, and target account so delegated authority remains attributable and narrow.

Approx. 4 min reading · Includes diagrams; allow extra time for reflection and linked resources.

Start reading ↓
About this learning content and editorial review
About this learning content: Courses, lessons, assessments, explanations and illustrations may be created with the help of artificial intelligence. We review and check the material and do our best to avoid incorrect or outdated information, but mistakes, omissions or ambiguous questions may remain. Please verify information before relying on it for professional, security, legal or operational decisions. Read the full notice or report an issue.

Your focus

What you’ll learn

  • Identify the sponsoring, deciding, executing, and affected principals in an agent action.
  • Define a task-scoped grant that cannot silently accumulate broader authority.

Develops a contextual authorization model using distinct non-human identity, task-scoped grants, scope attenuation, separation of duties, and target-side policy.

Acting for a person is not the same as being that person

The quickest prototype runs the support agent under an employee’s account. It can reach everything the employee can reach, and downstream services record the employee as the caller. That convenience collapses responsibility and execution into one identity. Investigators cannot reliably distinguish a human action from an agent action, and the agent inherits permissions that have nothing to do with the active ticket.

Separate the sponsoring principal from the executing principal. The employee or workflow owner authorizes a bounded task. A distinct agent instance or workload identity performs it. The tool service validates that identity and the delegated context. The customer account remains the target, not an identity the agent may freely impersonate. This preserves accountability without pretending that the model itself holds a credential.

NIST’s current agent-identity work emphasizes distinct, verifiable non-human identity and the ability to relate an agent to its sponsor and current authority. The design is still evolving, so avoid claims that one credential format solves every environment. The stable lesson is architectural: do not hide agent activity inside a broad human session or an undifferentiated shared service account.

The sponsor, agent, executing credential, and affected customer remain distinct and related.
Four principals participate in one refund — The sponsor, agent, executing credential, and affected customer remain distinct and related.

Authorization belongs to the current task

Identity answers who or what is acting; authorization answers what this action may do now. The support agent receives a grant tied to the case, customer, allowed operation, maximum amount, expiry, and required confirmation. A later tool call is evaluated against that context. Possessing a valid agent credential does not make every reachable operation appropriate.

Authority should attenuate as it moves down a delegation chain. A child agent or tool receives no more authority than its parent and preferably less. Avoid collecting scopes across steps until the workflow holds a powerful union of permissions. Issue short-lived credentials near the action, bind them to an intended audience, and prevent a token meant for one service from being replayed at another.

Evaluate policy at the moment of action because the relevant facts can change. The ticket may close, the employee may lose access, the refund may exceed a daily limit, or the content may become high risk. A login-time decision cannot represent all later actions in an adaptive workflow.

A broad organizational permission becomes a case-bound, operation-bound, short-lived grant before it reaches the refund service.
Delegated authority narrows at every handoff — A broad organizational permission becomes a case-bound, operation-bound, short-lived grant before it reaches the refund service.

Make denial and revocation part of the design

A secure path explains how authority ends. Revoke the task grant when the case closes, confirmation is withdrawn, risk changes, or the agent crosses a boundary. Stop both credentials and network paths where necessary; disabling the chat interface alone may leave queued jobs or tool sessions active.

Record why authorization was allowed or denied without storing unnecessary sensitive content. The policy version, rule, subject, agent, task, operation, target, and outcome often support review. The next lesson carries these identities and grants through an MCP connection, where another server and another set of tool definitions enter the trust chain.

Resources