Claude Agent SDK and Descope show the agent identity control gap

At a glance

What this is: Descope’s tutorial shows how a Claude-based agent can authenticate with verified session identity while brokering API keys and OAuth tokens at runtime instead of storing secrets in code.

Why it matters: This matters because IAM teams now have to govern agent sessions, tool scopes, and credential retrieval as one control surface rather than treating secrets, access, and audit as separate problems.

Context

AI agent security starts with a governance assumption: that access can be defined, reviewed, and rotated around credentials that stay stable long enough to manage. Once an agent can call APIs, run shell commands, and chain tools in one session, that assumption becomes fragile because the credential lifecycle moves to runtime.

Descope’s tutorial is about a practical identity pattern for a Claude-based agent, not a theoretical architecture. It shows how session tokens, scoped tool access, and credential brokering can keep secrets out of code, while still leaving practitioners with a harder question: how do you govern access that exists only when the agent is actively operating?

For IAM, IGA, PAM, and NHI teams, the key issue is not whether the agent can authenticate. The issue is whether the programme can prove who or what used each tool, what scope it held at the moment of use, and whether the access boundary was narrow enough for the task at hand.

Key questions

Q: How should security teams govern AI agents that rely on shared runtime credentials?

A: Security teams should treat every AI agent as a workload identity with a defined task boundary, then issue only the minimum access required for that task. Shared credentials should be retired where possible because they obscure accountability, widen blast radius, and make revocation harder after the task completes.

Q: Why do runtime credentials reduce secrets risk but not identity risk?

A: Runtime brokering reduces the chance of hardcoded secrets, leaked config files, and broad reusable tokens, but it does not remove the need to govern who or what can trigger access. The identity risk shifts to authorisation, scope, and evidence, because the agent may still act with more reach than a human reviewer expects.

Q: What breaks when agent access is not scoped to the task?

A: Standing privilege becomes the main failure mode. Without task scoping, an agent can reach systems, data, or actions that were never needed for the original request, increasing blast radius and audit difficulty. The same problem appears when revocation is slow, because the privilege outlives the work it was supposed to support.

Q: What is the difference between agent session identity and downstream service credentials?

A: Session identity proves which agent or user is authorised to act, while downstream service credentials prove access to an external system such as an API or SaaS app. They should be managed separately, with the session controlling when a credential may be fetched and the vault controlling what the credential can reach.

Technical breakdown

Runtime credential brokering for AI agents

The pattern in this tutorial separates agent identity from downstream service credentials. The Claude Agent SDK authenticates the agent session first, then the MCP server uses that verified identity to request the right credential from Descope at the moment a tool needs it. That means the agent does not hold the WeatherAPI key, Google OAuth token, or Notion credential directly. Instead, credential retrieval becomes a controlled lookup tied to a user identity and tool scope. This is a non-human identity pattern, not a human login flow, because the security boundary is the session-to-tool handoff rather than a browser-based authentication event.

Practical implication: Treat runtime credential brokering as a control boundary and verify that the agent never receives reusable secrets directly.

Per-tool scopes and hidden privilege

The tutorial also shows scope enforcement at the tool layer, where a missing permission hides the tool rather than exposing an error. That matters because agentic access often fails by overexposure, not just by compromise. If the session token only permits weather lookup and calendar read access, then the agent should not discover or call tools outside that boundary. This is the difference between authenticated presence and authorised capability. In NHI terms, the important design choice is to bind each tool invocation to a narrow entitlement set, not to let the agent inherit broad environment permissions simply because it is running inside a trusted process.

Practical implication: Map every tool to an explicit scope and confirm that unauthorised tools are not callable or visible to the agent.

Audit logging for delegated agent actions

The tutorial’s audit trail links each authorisation and credential lookup back to a user identity. That is the minimum viable evidence model for agentic systems because the operator, the agent session, and the external service call are not the same thing. Without that linkage, incidents become attribution problems rather than security events. Auditability here is not just logging success or failure. It is preserving who approved or triggered the session, which credential was fetched, and which tool was invoked. For identity governance, that creates a record that can support review, incident investigation, and access recertification around non-human activity.

Practical implication: Require traceable logs that join user identity, agent session, credential fetch, and tool invocation into one audit path.

Threat narrative

Attacker objective: The attacker objective in this pattern would be to abuse delegated agent access to reach external services, data, or actions that were never meant to be exposed to the session.

1. Entry begins when the agent authenticates to the local MCP server and receives a session token that allows tool execution.
2. Credential access occurs when the server retrieves external API keys and OAuth tokens at runtime on behalf of the session identity.
3. Escalation is avoided only if per-tool scopes hold, because broader permissions would let the agent act beyond the current task.
4. Impact would come from unchecked tool reach, where an agent could query, write, or connect to external systems with more privilege than intended.

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 an identity control problem, not a secrets-storage problem. This tutorial shows the security boundary moving from code to session, where credentials are fetched only when a tool is invoked. That shifts the governance question from where secrets live to who or what can trigger their use. The practical conclusion is that NHI programmes must treat agent sessions as first-class identities.

Access review processes assume access persists long enough to be reviewed, but agent tool access may exist only for the duration of a task. That assumption fails when the agent fetches credentials at runtime, uses them once, and discards them before a reviewer ever sees a stable entitlement. The implication is that recertification alone cannot govern agentic access; issuance-time controls become the decisive layer.

Tool scoping, not model capability, is the real control plane for Claude-style agents. The tutorial’s strongest security value is that each tool has a narrow scope and the agent never directly sees the underlying credentials. That is the right mental model for agentic governance: control what the agent can invoke, when it can invoke it, and what evidence remains after invocation.

Auditability must join user identity, agent session, and credential event into one record. Without that linkage, agent activity looks like anonymous automation even when the original user was authenticated. For identity security teams, this is where agentic governance converges with NHI oversight, because delegated runtime access without attributable logs is effectively ungoverned access.

Ephemeral credential trust debt: the more often credentials are brokered at runtime, the more the organisation relies on every upstream identity assertion being correct in real time. That creates a governance debt that is invisible in static reviews but material in production. Practitioners should treat that debt as a control design constraint, not a tuning issue.

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 Observability, Audit and Incident Response Guide

What this signals

Agent identity has moved from speculative architecture to operational governance. The pattern here is not about whether an AI agent can use tools, but about whether the organisation can make each tool call attributable, scoped, and reviewable. That is why agent sessions now need the same governance discipline as any other non-human identity.

Access review alone will not be enough for agents that broker credentials on demand. If the credential exists only for the life of a tool call, the programme has to verify issuance, scope, and logging at the moment of use rather than waiting for a periodic entitlement review. This is the control shift IAM leaders should prepare for.

Runtime-brokered access creates an identity blast radius problem. The fewer the controls between a session token and a powerful downstream action, the easier it is for one successful agent invocation to expose multiple external systems. Practitioners should watch how quickly their current programme can prove and limit that blast radius.

For practitioners

• Define the agent session as the governed identity Require every agent instance to authenticate to tools through a verified session identity before any external call is allowed. Do not let runtime credentials or tool access originate from code, local files, or shared environment variables.
• Bind each tool to a narrow scope Assign per-tool scopes for read, write, and connect actions so the agent can only invoke the capability needed for the task. Remove tool visibility entirely when the scope is absent, rather than relying on downstream failures.
• Centralise credential retrieval in a vault layer Broker API keys and OAuth tokens through a managed identity layer so the agent never handles reusable secrets directly. Make each fetch user-specific and task-specific, with no persistence in the codebase.
• Join audit events across identity, scope, and tool use Log the authenticated user, the agent session, the fetched credential, and the tool invocation in one traceable record. Use that record for incident review, access certification, and exception handling.

Key takeaways

• This tutorial shows that agentic security is really an identity governance problem, because the controlling question is who can trigger runtime access, not where the secret sits.
• The architecture relies on per-tool scoping, session identity, and audit logging to keep Claude-based agent actions narrow and attributable.
• If runtime credentials are not joined to a verifiable identity and a task-specific scope, the agent can still outgrow the control model even when secrets never touch code.

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.
• Tool Scope: The specific set of actions or resources a tool-enabled identity is allowed to use. For MCP, scope is the practical boundary that keeps a model-connected server from turning into broad system access. Weak scope design creates unnecessary blast radius and complicates later revocation.
• 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.