Notifications
Clear all
Topic starter
15/08/2026 8:03 pm
TL;DR: The core issue is not agent capability but whether identity controls can keep pace with autonomous tool use, according to Descope’s tutorial on a Claude Agent SDK implementation that keeps AI agent secrets out of code by brokering session tokens, API keys, and OAuth credentials at runtime while enforcing per-tool scope and audit logging.
NHIMG editorial — based on content published by Descope: How to Secure an AI Agent With Claude Agent SDK + Descope
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Descope’s guide to securing a Claude Agent SDK workflow with runtime identity →
AI agent identity controls: are runtime credentials enough?
Explore further
15/08/2026 8:03 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Claude Agent SDK and Descope show the agent identity control gap
