Notifications
Clear all
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.
NHIMG editorial — based on content published by Descope: How to Secure an AI Agent With LlamaIndex + Descope
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in current deployments.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that call APIs instead of using a UI?
A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.
Q: Why do AI agents complicate existing IAM and NHI controls?
A: They complicate control design because they can select actions at runtime, call multiple APIs, and move authority across systems without a human session boundary.
Q: What breaks when AI agent access relies on long-lived secrets?
A: Long-lived secrets let AI agents carry persistent access far beyond the task they were created for.
Practitioner guidance
- Implement per-request credential brokering Move API keys and OAuth tokens out of code, local files, and environment variables, then retrieve them only at the moment a tool call is authorised.
- Enforce scope checks before tool exposure Tie session scopes to specific tools so an agent cannot even discover or invoke capabilities that are outside the current task boundary.
- Separate user identity from borrowed credentials Use a verified session identity for the agent and keep third-party credentials attached to the user and connection, not to the agent runtime.
What's in the full article
Descope's full tutorial covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup of the LlamaIndex agent and MCP server used in the demo.
- Exact Descope connection configuration for API keys, OAuth, and DCR-provisioned credentials.
- Code-level examples for scope enforcement, token retrieval, and per-user audit logging.
- The full end-to-end workflow that creates the Notion page after weather and calendar lookups.
👉 Read Descope's tutorial on securing an AI agent with LlamaIndex →
AI agent identity control gaps: are your runtime credentials governed?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
19/08/2026 4:14 pm
Agentic identity control is now a runtime authorisation problem, not a code review problem. This tutorial makes the key governance shift explicit: the agent can call tools, but the credentials never need to live in the agent codebase or environment. That changes the control question from 'is the code secure?' to 'is every action brokered, scoped, and recorded at runtime?' For IAM and NHI teams, the practical conclusion is that identity policy must sit on the execution path, not around it.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, which means nearly half lack a reliable compliance and investigation record.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: Securing AI agent identities with runtime credentials and audit trails
