How do I give an AI agent its own scoped identity and short-lived access tokens?

To provide an AI agent with its own scoped identity and short-lived access tokens, implement a secure harness that mediates all agent actions and issues capability tokens based on attested intent. This approach prevents broad access and ensures actions align with specific tasks.

• Implement a Secure Harness: A secure harness acts as a unified control layer that integrates identity, tool mediation, context governance, telemetry, intervention, and auditability. This infrastructure makes agent behavior visible, governable, and accountable.
• Assign Clear Agent Identities: Every agent must have a clear identity defining its representation, delegated authority, and permitted scope of action. This involves tracking all identity relationships, understanding their composition, and detecting when an agent's effective permissions exceed its intended scope. This addresses the NIST AI RMF function of Govern by establishing clear accountability.
• Utilize Intent-Based Access Control (IBAC): Beyond traditional access control, IBAC ensures that an agent's actions are consistent with its currently authorized intent. When a task is initiated, an orchestrator mints an intent token capturing the natural-language goal, scope of resources, expected action types, and a time-to-live (TTL). Downstream policy decision points evaluate this active intent token, rejecting actions outside the declared scope. This helps mitigate OWASP LLM Top 10 risks like Intent Drift through Prompt Injection (LLM01) and Privilege Escalation through Tool Composition (LLM03).
• Issue Short-Lived, Narrowly Scoped Capability Tokens: Authority should be conveyed through unforgeable, narrowly scoped capability tokens, not ambient permissions. These tokens are short-lived, embed the intent ID, and are passed to downstream services. This prevents credential theft and replay by binding credentials to workload attestation and having short TTLs (minutes, not hours). This also addresses the Confused Deputy problem by ensuring that Agent B receives a capability token strictly narrower than Agent A's, scoped to the specific subtask.
• Avoid Anti-Patterns: Do not use an "omnipotent agent service account" that is broadly scoped for all agent instances, as this collapses identity dimensions and makes auditing meaningless. Also, avoid passing user credentials directly to the agent; instead, use token exchange to a narrower delegated credential.
• Secure Credential Handling: For external services, store tokens in a secure vault at session creation time. When a tool is called, a dedicated proxy fetches the real credential from the vault, ensuring the harness and sandbox never directly handle the real credential. For Git repositories, clone the access token into the git remote URL during sandbox initialization so the agent loop never directly handles the token string.