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.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “How to Secure an AI Agent With Claude Agent SDK + Descope”.
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.
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.
Q: What breaks when agent access is not scoped to the task?
A: Standing privilege becomes the main failure mode.
Practitioner guidance
- 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.
- 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.
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 8:03 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Claude Agent SDK and Descope show the agent identity control gap