Claude Agent SDK and Descope show the agent identity control gap

At a glance

What this is: This is a Descope tutorial on securing a Claude-based AI agent with runtime identity, scoped tool access, and centralized credential brokerage.

Why it matters: It matters because IAM teams now have to govern agents that call tools, hold access, and leave audit trails, using controls designed for both non-human identities and human accountability.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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.

👉 Read Descope’s guide to securing a Claude Agent SDK workflow with runtime identity

Context

AI agent identity is no longer a theoretical problem. Once an agent can call APIs, execute shell commands, query databases, and connect to SaaS platforms, the issue shifts from model output quality to who or what is authorised to act, which credentials are used, and how those actions are traced.

This tutorial uses a Claude-based agent to show a runtime identity pattern for non-human identities: the agent authenticates with a verified session token, while Descope brokers API keys and OAuth tokens on demand. That is a useful architectural pattern, but it also exposes how quickly hardcoded secrets, broad scopes, and weak audit assumptions become a governance problem.

The starting position here is typical of early agent deployments: capability arrives before governance maturity. That gap is now common across agentic AI programmes, workload identity, and IAM operations.

Key questions

Q: How should security teams govern AI agent tool calls without exposing credentials?

A: Security teams should place credentials in a separate execution layer, not in the model context, and bind every tool call to a distinct agent identity. The key controls are scoped consent, execution-time secret injection, and unified audit logging. That way the model can request actions without ever seeing the material that authorises them.

Q: What breaks when AI agents rely on long-lived API keys?

A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs. Once the key is reused across tasks, revocation becomes slow and unreliable. Short-lived credentials are safer because they reduce the window in which exposure can be exploited.

Q: How do you know if AI access controls are actually working?

A: They are working only if you can answer three questions consistently: which identity accessed the system, which data it touched, and whether that access matched the intended business use. If audit logs cannot produce that chain, the control is partial and the exposure is still active.

Q: Why do AI agents complicate traditional IAM and PAM controls?

A: AI agents complicate IAM and PAM because they can make decisions, chain tools, and act faster than human review cycles can respond. They also blur the line between authentication and authorization, since the same identity may trigger multiple actions after a single approval. That means organizations need policy, telemetry, and revocation designed for autonomous behavior, not just human login events.

Technical breakdown

Runtime identity for AI agents and MCP tools

The tutorial separates inbound and outbound identity. Inbound, the agent authenticates to the MCP server with a Descope-issued session token that is validated before any tool runs. Outbound, the server fetches the right credential for the connected service only when a tool is called. That pattern matters because it keeps the agent from ever holding the secret directly, while still letting the system act on the user’s behalf. It also means tool access is mediated by identity rather than embedded in code or environment variables.

Practical implication: move agent authentication and tool brokering out of the application layer and into a controlled identity service.

Why hardcoded keys fail in agentic workflows

Hardcoded keys, local config files, and broad environment variables assume the credential will remain stable long enough to be managed manually. Agentic workflows break that assumption because a single session can touch multiple services, each with different access rules and revocation needs. If the same secret is reused across tools, the blast radius expands and audit evidence becomes ambiguous. The problem is not just leakage, but lifecycle mismatch between long-lived credentials and short-lived, task-scoped actions.

Practical implication: treat every agent credential as a lifecycle object, not a static configuration value.

Per-tool scopes and centralized audit logging

The tutorial’s access model is built around fine-grained tool scopes such as calendar read or weather key read, with logging tied to the user identity that authorized the action. This is the right direction for agent governance because it turns every tool call into a traceable event and prevents a single connected identity from inheriting broad platform access. In practice, that is the difference between an agent being observable and an agent being opaque.

Practical implication: enforce tool-level authorization and retain logs that link the agent, user, scope, and downstream credential used.

Threat narrative

Attacker objective: The attacker objective is to turn a legitimate agent workflow into a high-trust access path for data exposure, credential abuse, or unauthorised system actions.

1. Entry begins when an AI agent is granted external tool connectivity through APIs, shell execution, database access, or SaaS integrations, creating a new identity surface that can be abused if the session or credential layer is weak.
2. Escalation occurs when the agent receives broad or reusable credentials that let it cross service boundaries, especially where scopes are wider than the task and audit visibility is incomplete.
3. Impact follows when the agent can access or modify data, trigger actions in third-party systems, or expose secrets through chained tool use without a clear revocation or review boundary.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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 identity brokerage is becoming the default control plane for agents. Once an AI agent can call external tools, the security question is no longer where the model runs, but where credential decisioning happens. A verified session token plus on-demand credential retrieval is materially safer than placing secrets in code or config, because it separates identity proof from secret storage. The practitioner conclusion is simple: if the agent touches tools, the identity layer must sit between intent and execution.

Secret sprawl is the wrong pattern for agentic workloads. This tutorial is useful precisely because it demonstrates a safer alternative to environment-variable keys and hardcoded tokens. Those patterns were already fragile for service accounts, and they are even weaker when an agent can chain multiple tools in one runtime session. The implication is that NHI governance now has to cover agent-issued access the same way it covers workload credentials and API keys.

Fine-grained tool scopes matter more than model sophistication. The agent here can reason over weather, calendar, and planning, but governance still depends on whether each tool is separately authorised and logged. That is the operational boundary that prevents a capable agent from becoming a broad-access identity. Practitioners should read this as a scope-design problem, not an AI capability problem.

Agent auditability must tie the user, the session, and the downstream credential together. Central logs are only useful when they answer who authorised the call, which identity was used, and what service was reached. Without that chain, incident response and compliance both degrade into guesswork. The field is moving toward identity evidence for agents, not just telemetry from the model or the app.

Agent identity governance now sits at the intersection of IAM, PAM, and NHI controls. The same lifecycle logic that applies to service accounts now has to apply to session-bound agents with delegated SaaS access. That means access reviews, revocation, and segregation of duties cannot stop at the human user. Practitioners need a programme model that treats the agent as an accountable non-human actor, not as a hidden extension of the application.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• 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, according to SailPoint.
• For a broader control framework, see OWASP Agentic Applications Top 10 for the agentic risk patterns that runtime identity controls must address.

What this signals

Agentic identity is moving from experimental pattern to operational requirement. The gap between adoption intent and policy maturity means teams will be forced to govern agents before they are fully comfortable with them. That is not a reason to slow down; it is a reason to align IAM, PAM, and secrets governance around runtime access decisions now, using the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework as external anchors.

Credential brokerage will become a programme-level control, not an application detail. Once agents start calling multiple services, identity teams need a reusable pattern for token issuance, scope enforcement, and revocation across workloads and user-linked sessions. The organisations that can trace agent behaviour end to end will be able to support compliance and incident response; the rest will have to infer what happened after the fact.

Runtime scope is the new identity boundary. A tool call that is authorised at session start but cannot be constrained at execution time is still a governance failure. The practical shift is toward controls that can prove what the agent was allowed to do at the exact moment it acted, not just what the user approved at onboarding.

For practitioners

• Move agent credentials out of code and into a brokered vault Store API keys and OAuth tokens in a central identity layer, then fetch them only at runtime for the specific tool call that needs them. This reduces leakage from repositories, config files, and local environments while preserving per-user isolation.
• Enforce tool-specific scopes for every agent action Separate read, write, and administrative permissions at the tool level so a planning agent cannot inherit access it never needs. A session token should prove who the agent is, while each downstream credential should be scoped to the narrowest viable task.
• Log the full identity chain for every tool call Capture the user, the session token, the tool scope, the retrieved credential reference, and the downstream service response in one audit trail. That creates evidence for incident response, access review, and compliance reporting.
• Design for revocation before deployment Build a process for removing connected credentials, expiring sessions, and invalidating tool access without changing application code. If revocation is difficult, the agent is already too loosely coupled to the identity system.

Key takeaways

• AI agents create a governance problem only partially addressed by traditional IAM, because runtime tool use changes the identity surface.
• Runtime credential brokerage, per-tool scopes, and linked audit trails are the controls that separate observable agents from opaque ones.
• For IAM and NHI teams, the decisive question is no longer whether an agent can act, but whether every action can be constrained, traced, and revoked.

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.
• 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.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Identity Audit Chain: The linked record of who authorised an agent, which session was used, which credential was fetched, and what external system was reached. It turns agent activity into evidence that can support incident response, access review, and compliance reporting without reconstructing events from scattered logs.

What's in the full article

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

• The step-by-step Claude Agent SDK wiring for session authentication and MCP validation.
• The exact Descope connection setup for weather API, Google Calendar, and Notion credentials.
• The code-level flow for fetching user-scoped tokens at runtime without storing secrets in the agent.
• The audit and troubleshoot workflow that shows how each authorization event is logged.

👉 Descope’s full tutorial shows the credential flow, tool scopes, and audit path behind the demo.

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 security programme, it is worth exploring.