Securing AI agent identities with runtime credentials and audit trails

At a glance

What this is: This is a Descope tutorial on securing AI agent identities by brokering runtime credentials, enforcing tool-scoped access, and logging every credentialed action.

Why it matters: It matters because IAM teams need controls that follow agent execution in real time, not just static secrets hygiene, when AI agents interact with external systems on behalf of users.

Context

AI agent identity becomes a governance problem the moment an agent can call tools, touch external systems, and act on behalf of a user. In that model, the core risk is not only whether the agent is authenticated, but whether its credentials are scoped to the task and observable after use.

This tutorial sits in the runtime credential layer of agentic AI: session tokens, delegated credentials, and audit logs. Those controls matter because environment variables, local config files, and hardcoded keys do not give security teams a reliable way to constrain or reconstruct agent behaviour at runtime.

The article's central claim is that identity and credential handling must be separated from agent code if the agent is going to operate safely across multiple tools and users. That is a typical problem for early-stage agent builds, not an edge case.

Key questions

Q: What breaks when AI agents rely on static secrets?

A: Static secrets break the trust model because they are reusable, portable, and often broader than the task requires. In an agent workflow, that can expose more systems than intended and make it difficult to prove why access was granted. Short-lived, brokered credentials are a better fit for runtime decision-making.

Q: When should organisations prioritise audit trails over more secret rotation for AI agents?

A: Prioritise audit trails when agents can call multiple tools, touch user data, or act across systems where the main problem is not only leakage but attribution. Rotation still matters, but it does not tell you which session used the credential or what action followed. Logging every fetch and tool call is what makes delegated access governable.

Q: When does AI agent access become too broad for safe operation?

A: Access becomes too broad when an agent can reach systems unrelated to its primary task, especially if it can move from one tool to another without a policy check. The warning sign is not authentication failure. It is unnecessary privilege accumulation that increases blast radius if the agent is manipulated or compromised.

Q: How should security teams govern AI agents that use multiple identity layers?

A: Security teams should inventory every identity layer an agent can use, including static credentials, session identities, embedded tool identities, and any delegated relationships between agents. Governance fails when one layer is controlled while another remains open, because the agent can still act through the weaker path. Treat the layered identity surface as the actual access boundary.

Technical breakdown

How runtime credential brokering works for AI agents

The architecture separates the agent's own authenticated session from the credentials it borrows to reach third-party services. The agent logs in with DCR and PKCE, receives a session token, and presents that token to the MCP server on each tool call. The server then fetches the correct downstream credential for the current user and task, such as an API key or OAuth token, and the agent never handles the secret directly. This pattern reduces secret exposure in code and memory, but it also creates a new trust boundary around credential retrieval, scope enforcement, and session validation.

Practical implication: govern the brokered credential path as part of the agent's attack surface, not as an implementation detail.

Why per-user sessions matter more than shared secrets

The tutorial shows why a single shared secret model breaks down once an agent serves multiple users. A static environment variable cannot represent user-specific consent, delegated OAuth grants, or service-specific access isolation. Per-user connections let the platform store and return credentials tied to a specific identity, which means the same agent can operate across users without collapsing everything into one shared privilege set. That is an IAM design choice, not just a developer convenience. It turns the credential store into a governed access layer rather than a repository of keys.

Practical implication: replace shared credentials with user-bound or task-bound credential retrieval where multiple users or grants are involved.

Why audit trails are the control that makes agent identity usable

Agentic systems need more than authentication because tool use is distributed across reasoning steps, API calls, and delegated actions. Audit logging ties each credential access and tool invocation back to the specific identity and connection touched, creating an evidentiary trail for review, incident response, and accountability. Without that layer, you may know that an agent produced output, but not which credential path it used to get there. For AI agents, observability is part of identity security, not a separate monitoring concern.

Practical implication: require immutable, queryable logs for every credential fetch and tool invocation before allowing production agent use.

Threat narrative

Attacker objective: The objective is to turn agent-mediated delegated access into unsanctioned tool use that looks legitimate at the application layer but is not properly governed at the identity layer.

1. The attack entry point is the agent's runtime access to external systems through tool calls that depend on credentials fetched on demand.
2. Privilege escalation would occur if those credentials were shared, over-scoped, or stored in places the agent or surrounding process could reuse outside the intended task.
3. Impact would be unauthorized actions through APIs, calendars, documents, or files, with weak attribution if the brokered access path was not fully logged.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime credential brokering is now the control plane for AI agent identity. Once an agent can call tools, the question is no longer whether it has a secret, but whether that secret is issued, scoped, and revoked at the same pace as execution. This shifts governance from code-level secret storage to runtime identity control, which is where agent security really lives.

The assumption that access can be reviewed after the fact breaks under agentic execution. Access review processes were designed for persistent entitlements that remain visible long enough to certify. An AI agent can acquire, use, and discard a credential within a single task, so the review artifact may never exist in the state traditional governance expects. The implication is that identity governance has to move closer to issuance and tool invocation.

Per-user credential isolation is the right problem statement, but auditability is what makes it governable. Separate OAuth grants and static keys reduce blast radius, yet they do not solve accountability unless every fetch and tool use is traceable to the user and connection. That is the difference between delegated access and governable delegated access, and practitioners should treat it as a hard requirement.

Agentic identity is a lifecycle problem as much as an authentication problem. Joiner-mover-leaver thinking now applies to agent sessions, downstream connections, and the scopes attached to each tool. If the session starts cleanly but the credentials outlive the task or the user relationship, governance has already failed. Practitioners need to manage agent identity as a lifecycle, not as a one-time login event.

Identity blast radius becomes the decisive metric for production agents. The article's architecture is a useful pattern because it limits what the agent can see and what it can do at any one moment. That is the boundary security teams should measure, because production risk grows when one agent session can reach too many downstream systems, too broadly, for too long.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Agent identity governance now depends on whether the control plane can broker credentials at runtime without turning every tool call into a standing privilege problem. The practical shift is from storing secrets safely to proving that each session receives only the access needed for the current task.

Identity blast radius: The useful metric for AI agent programmes is not how many tools an agent can reach, but how narrowly each session is constrained when it reaches them. If one session can fan out across calendars, files, and APIs with the same trust level, the governance model is already too flat.

For practitioners, the important boundary is no longer the model or the workflow alone. It is whether runtime identity, delegated credentials, and audit evidence all line up closely enough to support review, containment, and offboarding after the fact.

For practitioners

• Separate agent identity from borrowed credentials Authenticate the agent with a distinct session identity, then broker downstream access through a controlled retrieval layer instead of embedding secrets in code, files, or environment variables.
• Scope every tool to the minimum delegated task Assign read-only or task-specific access to each external system so the agent can complete one workflow without inheriting broad reusable rights across unrelated services.
• Log each credential fetch and tool invocation Record the user, session, connection ID, and tool call for every runtime access event so review and incident response can reconstruct what the agent actually did.
• Treat multi-user agents as credential isolation problems Use per-user connection storage for OAuth grants and API keys so one person's authorization cannot become a shared privilege pool for every agent session.
• Define offboarding for agent sessions and their grants When a user, tool, or workflow is retired, revoke the associated agent session, downstream token, and stored connection rather than leaving dormant access in place.

Key takeaways

• AI agents introduce a runtime identity problem because they can call tools and borrow credentials during execution rather than through static, predeclared access paths.
• The strongest control pattern is to separate the agent's own session identity from the credentials it uses to reach external systems, then log every access event.
• If access reviews and secret storage are the only controls in place, the programme will miss the real boundary where agent behaviour becomes governable.

Key terms

• Runtime Credential Brokering: The practice of issuing credentials only when a workload or agent actually needs them, then letting them expire or become unusable after the task is complete. This reduces standing access and creates a clearer audit trail than storing long-lived secrets in pipelines or agents.
• Developer Session Identity: Developer session identity is the effective identity context created when a person, assistant, plugin, and repository all act together during software creation. In practice, it combines human permissions with machine actions, which means governance must account for delegated tool use, not just the developer’s login.
• Delegated tool privilege: Delegated tool privilege is the effective authority an AI agent inherits from the systems it can call, even when it is not the owner of those systems. It is the practical blast radius created by connectors, credentials, and runtime permissions. This is often the real control boundary in agentic environments.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.