Topic starter
19/08/2026 3:31 pm
TL;DR: AI agents that call APIs, query databases, and write files quickly outgrow shortcut security patterns such as environment variables and hardcoded keys, according to Descope's tutorial on LlamaIndex integration. The real governance problem is that access boundaries drift while auditability and rotation discipline lag behind the agent's runtime behaviour, leaving identity control weak exactly where action occurs.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “How to Secure an AI Agent With LlamaIndex + Descope”.
Key questions
Q: What breaks when AI agents rely on static secrets?
A: Static secrets break the trust model because they are reusable, portable, and often broader than the task requires.
Q: When should organisations prioritise audit trails over more secret rotation for AI agents?
A: Prioritise audit trails when agents can call multiple tools, touch user data, or act across systems where the main problem is not only leakage but attribution.
Q: When does AI agent access become too broad for safe operation?
A: Access becomes too broad when an agent can reach systems unrelated to its primary task, especially if it can move from one tool to another without a policy check.
Practitioner guidance
- Separate agent identity from borrowed credentials Authenticate the agent with a distinct session identity, then broker downstream access through a controlled retrieval layer instead of embedding secrets in code, files, or environment variables.
- Scope every tool to the minimum delegated task Assign read-only or task-specific access to each external system so the agent can complete one workflow without inheriting broad reusable rights across unrelated services.
- Log each credential fetch and tool invocation Record the user, session, connection ID, and tool call for every runtime access event so review and incident response can reconstruct what the agent actually did.
Bottom line: AI agents introduce a runtime identity problem because they can call tools and borrow credentials during execution rather than through static, predeclared access paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:14 pm
Runtime credential brokering is now the control plane for AI agent identity. Once an agent can call tools, the question is no longer whether it has a secret, but whether that secret is issued, scoped, and revoked at the same pace as execution. This shifts governance from code-level secret storage to runtime identity control, which is where agent security really lives.
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: How should security teams govern AI agents that use multiple identity layers?
A: Security teams should inventory every identity layer an agent can use, including static credentials, session identities, embedded tool identities, and any delegated relationships between agents. Governance fails when one layer is controlled while another remains open, because the agent can still act through the weaker path. Treat the layered identity surface as the actual access boundary.
👉 Read our full editorial: Securing AI agent identities with runtime credentials and audit trails