Securing AI agent identities with runtime credentials and audit trails

At a glance

What this is: This tutorial shows how an AI agent can authenticate with a verified session identity while runtime credentials are brokered separately through a managed identity layer.

Why it matters: It matters because IAM teams must govern agentic AI as a credentialed actor, not just as a chatbot, or per-tool access, auditability, and offboarding will fail.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in current deployments.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Descope's tutorial on securing an AI agent with LlamaIndex

Context

AI agent identity governance is different from ordinary application access because the agent is not just reading data, it is acting on behalf of a user across multiple tools and services. In this tutorial, Descope frames that problem through verified session identity, scoped credential brokering, and audit logging for a LlamaIndex-based agent.

The operational gap is familiar to IAM and NHI teams: credentials live in environment variables, local config files, or hardcoded keys, and the agent inherits far more access than any single task requires. Once an AI agent can call external services at runtime, the security model has to cover who it is, what it can borrow, and what gets recorded after each call.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do AI agents complicate existing IAM and NHI controls?

A: They complicate control design because they can select actions at runtime, call multiple APIs, and move authority across systems without a human session boundary. That breaks assumptions built into static entitlements and traditional service account management. Governance has to account for delegated action, changing context, and auditability across the full execution chain.

Q: What breaks when AI agent access relies on long-lived secrets?

A: Long-lived secrets let AI agents carry persistent access far beyond the task they were created for. That increases theft risk, complicates offboarding, and makes it harder to prove scope at audit time. Secretless, short-lived access is safer because the credential exists only for the current task and runtime context.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

Why runtime credential brokering matters for AI agents

The tutorial separates the agent's own identity from the credentials it borrows to reach third-party systems. The agent authenticates once through a verified session token, then the MCP server fetches the right credential at tool-call time, such as an API key or OAuth token, and discards it after use. That pattern reduces secret exposure in code and local storage, but it also makes the server the control point for identity, scope, and audit. The real technical shift is that tool access becomes request-bound rather than environment-bound.

Practical implication: treat the broker as part of the trust boundary and require every tool call to revalidate identity and scope.

How verified session tokens and scope checks constrain agent tools

The tutorial uses a DCR and PKCE login flow to issue a session token, then applies scope-based tool gating before the agent can even see a function. That matters because the token does not just identify the caller, it determines which tools are exposed and which actions are rejected before execution. In practice, this is closer to runtime authorisation than classic authentication. For agentic systems, the scope model must line up with the actual task surface, or the agent will still be over-privileged even if it is technically authenticated.

Practical implication: map scopes to individual task classes and validate that hidden tools stay hidden unless the session explicitly authorises them.

Why audit trails are a governance control, not just logging

The tutorial's audit layer records credential access, authorisation events, and the identity that triggered each tool call. For AI agents, that is not incidental telemetry. It is the only reliable way to reconstruct which action came from which session and which connection was touched. Without that record, per-user credential isolation and delegated access are hard to prove after the fact, especially when the agent chains weather, calendar, and document creation into one workflow. Auditability becomes part of the control plane for agentic identity.

Practical implication: require connection-level audit events that can be tied back to a specific agent session and user identity.

NHI Mgmt Group analysis

Agentic identity control is now a runtime authorisation problem, not a code review problem. This tutorial makes the key governance shift explicit: the agent can call tools, but the credentials never need to live in the agent codebase or environment. That changes the control question from 'is the code secure?' to 'is every action brokered, scoped, and recorded at runtime?' For IAM and NHI teams, the practical conclusion is that identity policy must sit on the execution path, not around it.

Per-tool credential isolation is the named concept this architecture depends on. Weather API keys, OAuth tokens, and DCR-provisioned credentials are all handled separately, tied to user identity, and retrieved only when a tool is called. That is a stronger model than shared environment variables, but it only works if the lifecycle of each credential is owned and auditable. The implication is that agent governance must be designed around discrete credential objects, not one broad platform secret.

Access boundaries drift quickly when agents can chain multiple services in one session. The article shows an agent pulling weather, calendar, and document data into a single workflow, which is exactly where over-privilege becomes hard to see. Traditional IAM assumptions about a stable request, a single API, or a fixed service principal do not hold cleanly here. The practical conclusion is that identity governance must evaluate the full action chain, not isolated tool calls.

Auditability is the difference between delegated action and ungoverned automation. Descope's audit and troubleshoot view gives the operator a record of which identity touched which connection and when. That matters because agentic systems can otherwise create a false sense of control while leaving no trustworthy evidence trail. For practitioners, the control objective is not merely to log events, but to make the agent's delegated behaviour reconstructable after the fact.

Secrets sprawl becomes an identity problem as soon as agents are allowed to operate across multiple services. The article is really about replacing hidden credentials with managed connections, verified sessions, and per-request retrieval. That aligns with OWASP NHI principles and the Zero Trust assumption that no runtime actor should be trusted implicitly. The conclusion for identity teams is that agentic AI should be governed like a workload identity with accountability, not like a UI feature with a chatbot front end.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, which means nearly half lack a reliable compliance and investigation record.
• For a deeper control perspective, see OWASP NHI Top 10 for the agentic risk categories that runtime governance must cover next.

What this signals

Per-request brokering is becoming the practical dividing line between governed agents and improvised automation. Once AI systems can call multiple external services, the question is not whether they are intelligent, but whether the identity layer can still prove what they were allowed to do. Teams that already use the OWASP NHI Top 10 should now map each agent tool to a discrete execution entitlement and revoke anything that cannot be tied to a business task.

Agent auditability has to be designed as an operational control, not bolted on as telemetry. If the platform cannot reconstruct which session touched which connection, incident response will always lag the real blast radius. That is why agentic identity programmes should align with NIST AI Risk Management Framework governance expectations rather than treating LLM tools as ordinary SaaS integrations.

Per-tool credential isolation: This is the control pattern where each external service credential is retrieved only for a specific request and never exposed to the agent runtime. It reduces secret sprawl, but it also raises the bar for lifecycle ownership, because every connection now needs scoped review, revocation logic, and an auditable user binding.

For practitioners

• Implement per-request credential brokering Move API keys and OAuth tokens out of code, local files, and environment variables, then retrieve them only at the moment a tool call is authorised.
• Enforce scope checks before tool exposure Tie session scopes to specific tools so an agent cannot even discover or invoke capabilities that are outside the current task boundary.
• Separate user identity from borrowed credentials Use a verified session identity for the agent and keep third-party credentials attached to the user and connection, not to the agent runtime.
• Record connection-level audit events Capture which session touched which connection, which tool was called, and what credential class was retrieved so incident review can reconstruct the sequence.

Key takeaways

• AI agents become materially harder to govern when they can reach multiple services through delegated credentials instead of fixed application secrets.
• Runtime identity, scope enforcement, and audit trails are the controls that separate a usable agent architecture from a blind automation path.
• Identity teams should design for per-request access and reconstructable action history, because static secrets and broad permissions no longer match the way agents operate.

Key terms

• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
• Credential Brokering: Credential brokering is the process of using a trusted identity proof to issue a separate credential for a target system that cannot accept the original identity natively. It is useful for compatibility, but it also becomes a control point for scope, duration, logging, and revocation.
• Per-tool scope: Per-tool scope is the practice of limiting an identity to the specific functions it needs for a task rather than the full platform surface. In agentic environments, scopes must be evaluated at runtime because the same agent may call different tools in one session.
• Verified session identity: Verified session identity is a trusted runtime identity established after authentication and used to authorise subsequent actions. For agents, it is the anchor for deciding what can be called, what credentials can be borrowed, and what gets written to the audit trail.

What's in the full article

Descope's full tutorial covers the operational detail this post intentionally leaves for the source:

• Step-by-step setup of the LlamaIndex agent and MCP server used in the demo.
• Exact Descope connection configuration for API keys, OAuth, and DCR-provisioned credentials.
• Code-level examples for scope enforcement, token retrieval, and per-user audit logging.
• The full end-to-end workflow that creates the Notion page after weather and calendar lookups.

👉 Descope's full tutorial shows the setup steps, code flow, and credential handling in detail.

Deepen your knowledge

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