On the audit of the cloud infrastructure of the fintech company in March of this year found a service account of the LLM agent with rights s3:* and iam
assRole. The token was not rotated for 9 months, and the agent used two API calls: s3:GetObject on one tank and bedrock:InvokeModel. The remaining 47 permits were in the dead cargo. Through the agent’s memory module (LangChain with a Redis backend), this token was available to anyone who will conduct prompt injection. The difference between "AI assistant answers questions" and "full access to the selling infrastructure" is one injection into the industrial and one overprivileged credential.
The scale of the problem: why NHI in AI agents is a blind spot SOC
Non-human identity (NHI) - service accounts, API keys, OAuth-tokens, certificates, pipeline-identity - have long ceased to be something auxiliary. In cloud-native environments, the ratio of NHI to human identities reaches 45:1 and above (Entro Security data confirmed by CSA publications). Between 2024 and 2025, the population of machine identities increased by 44%
AI agents are the fastest-growing category of NHI. Gartner predicts: 33% of enterprise applications will contain agentic AI by 2028 (in 2024 - less than 1%). Microsoft Copilot Studio has already transshipped a million created agents. At the same time, according to the CSA, more than 16% of organizations do not track the creation of identities associated with AI, and 85% are unsure of their ability to prevent an attack through the NHI.
For SOC teams, this is a specific headache: an AI agent is not a deterministic bot that drives the same lap. He decides in runtime, what APIs to call, in what sequence and with what parameters. Try to build a baseline on that.
CSA in its whitepaper formulates exactly: AI agents "accutings dynamically at runtime, spawn sub-gas, external APIs, write and execution code, and chains together disks that can of span"“Get permissions dynamically during execution, run subagents, call external APIs, write and execute code, and combine actions that can cover dozens of systems.”. Standard IAM processes confined to human accounts are not ready for this. And frankly, they won't be here soon.
Anatomy of attack: from the compromise of the token agent to the lateral movement
Attack path with a mapping on MITRE ATT&CK
Let’s look at the typical vector that I have observed in variations on multiple machine-to-machine authentication audits in LLM pypalines.
Phase 1 - Initial Access. The attacker exploits Prompt Injection (LLM01:2025 by OWASP Top 10 for LLM Applications). Through user input or a poisoned document in the RAG-pipeline, the agent receives instructions that changes his logic. In the context of NHI’s security in AI agents, it’s not a jailbreak for a “ridiculous response” – it’s the use of a legitimate credentials agent for illegitimate action. MITRE ATT&CK: T1078 (Valid Accounts). The agent acts on behalf of his service account, and from the point of view of IAM everything looks clean.
Phase 2 - Credential Access. The agent stores tokens to contact external services. In multi-agent systems (AutoGen, CrewAI), each sub-agent can hold its own set of credentials transmitted through shared memory or variable environments. MITRE ATT&CK: T1528 (Steal Application Access Token) - extraction of tokens from the memory module. If the agent is running on EC2/GCE without IMDS limitation T1552.005 (Cloud Instance Metadata API) gives temporary credentials through one HTTP request.
Specific script: LangChain-agent with access to Vault via AppRole. If secret_id According to the GitGuardian State of Secrets Sprav, in 2024, 23.77 million secrets flowed to public GitHub), prompt injection allows the agent to request an arbitrary secret from Vault. Vault has nothing to do with it - the excess rights of the NHI agent are vulnerable.
Phase 3 - Lateral Movement and Persistence. The received tokens are used to access related services: T1550.001 (Application Access Token). If the AI agent token contains the rights iam:AttachRolePolicy or analogues in Azure/GCP - the attacker fixes the persistence through T1098.003 (Additional Cloud Roles). In one of the AI-a-agent with rights to the Terraform state file could modify IAM-politics via IaC-pipeline - persistence without directly contacting the IAM API. Elegant if it wasn't so scary.
Insider threat: when a legitimate agent becomes an insider
Compromising LLM service accounts is essentially an insider threat. The compromised AI agent acts from its Valid NHI, with valid credentials, from the expected subnet. For SIEM, it looks like a legitimate process. Unlike an external attacker with a stolen password, there is no anomalous login, there is no impossible travel, there is no bruteforce - only an unusual set of API-chains. And if the baseline agent is already unstable because of undetermined nature - the anomaly drowns in noise.
According to Verizon DBIR, the stolen credentials is the most common initial access vector: 22% of all incidents. SpyCloud (Annual Identity Exposure Report) records millions of leaked API keys and tokens annually. For AI-related secrets (keys to the AI API, configuration currents of agents) growth was 81% for the year - the fastest among all categories of credentials, according to GitGuardian.
Tokens with excessive rights in LLM-PIplays
Overprivileged access - problem number two after the leak of secrets on OWASP NHI Top 10. For AI agents, it is even sharper: the developer gives the agent the maximum rights in prototyping, and the narrowing of the scope is postponed. Forever.
One token for all tool-calls. LLM agent via MCP (Model Context Protocol) or calling function accesses 5-7 services. Instead of individual credentials for each - one service account with all permissions. If one tool is compromised, blast radius covers all the others.
Long-lived credentials without rotation. NHI AI agents, by definition, "don't log out, can't use MFA, and are retired longed""does not leave the system, can not use multi-factor authentication and rarely leave" (Veeam). On one of the audits, I found the AWS access key for the SageMaker agent, which did not change 14 months - with the recommended rotation of 90 days. Fourteen months. For sale.
Orphaned identities. Data science team tests 10 variants of agents, each creates a service account. 8 agents are discarded, accounts remain active without a owner. Privileged access of machine identifiers to food resources - without the person responsible for their lifecycle.
Here is the minimum IAM policy limiting the scope of the LLM agent for RAG:
JSON:
{
"Version": "2012-10-17",
"Statement": [
{"Effect": "Allow", "Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::rag-docs-prod/*"},
{"Effect": "Allow", "Action": ["bedrock:InvokeModel"],
"Resource": "arn:aws:bedrock:us-east-1:*:model/anthropic.claude-*"}
]
}
According to the documents, the developer writes "scope will be minimal." In practice, most of the configurations I have tested is "Action": "s3:" or "Action": "". Guess which option is more common.
Detection-checklist: Correlation rules for NHI in SIEM
What to Monitor: Specific Alerates
For SOC commands working with API security tokens in AI systems, the following is a correctional ruler checklist. Each rule is tied to a specific TTP.
1. Anomalous API call pattern - the agent calls the API out of baseline (for example, iam:CreateUserwith the usual s3:GetObject) Indicator prompt injection through NHI. Related to T1078.
2. Credential usage from the unexpected source of the agent is used from an IP that does not match the VPC/deployment subnet. T1550.001.
3. Token usage outless execution window - for agents with a cron-schedule any activity outside the execution window - altrate.
4. Spike in API call volume - a sharp increase in the number of calls indicates data exfiltration or a selection of resources. T1528.
5. Access to secrets stores - an agent for Vault, Secrets Manager or Parameter Store outside the casino line. T1552.005.
6. Cross-account access - NHI agent accesses resources in someone else's account / project. T1550.001.
7. Annomalous role - the agent takes the role (AssumeRole), which has not been used before. T1548.005 (Temporary Elevated Cloud Access).
Example of Sigma-like rule for detection of anomalous AssumeRole:
YAML:
title: AI Agent NHI - Anomalous Role Assumption
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventName: AssumeRole
userIdentity.type: AssumedRole
userAgent|contains: 'langchain'
filter:
requestParameters.roleArn|endswith:
- 'rag-reader-role'
condition: selection and not filter
level: high
Building a baseline for undetermined agents
For a deterministic service account, baseline is built in 14-30 days on a fixed set of API-calls. With AI agents, this approach breaks down – their behavior depends on user samples, and two identical queries can give rise to completely different chains of calls.
The work scheme that I ran through several projects:
• Limit the set of available tools at the MCP server config (Kifiable function confa) is the top boundary of baseline
• Log in each tool-call with metadata: which tool, parameters, initiated by the user or automatically
• Build baseline by category: read / write an admin, not on specific calls
• Any action of the admin category from NHI agent is analt without exception. No options.
Least privilege for autonomous systems - practical checklist
Adjustments to the environment
The cheat sheet is applicable to AI-agents in:
• AWS : IAM + Bedrock/SageMaker, STS for short-lived tokens
• Azure : Managed Identities + OpenAI Service
• GCP : Service Accounts + Vertex AI, Workload Identity Federation
• On-premise : HashiCorp Vault 1.15+ for secrets, SPIFFE/SPIRE 1.9+ for machine identity
• Hybrid : cloud LLM + on-prem data sources via VPC peering
assRole. The token was not rotated for 9 months, and the agent used two API calls: s3:GetObject on one tank and bedrock:InvokeModel. The remaining 47 permits were in the dead cargo. Through the agent’s memory module (LangChain with a Redis backend), this token was available to anyone who will conduct prompt injection. The difference between "AI assistant answers questions" and "full access to the selling infrastructure" is one injection into the industrial and one overprivileged credential.The scale of the problem: why NHI in AI agents is a blind spot SOC
Non-human identity (NHI) - service accounts, API keys, OAuth-tokens, certificates, pipeline-identity - have long ceased to be something auxiliary. In cloud-native environments, the ratio of NHI to human identities reaches 45:1 and above (Entro Security data confirmed by CSA publications). Between 2024 and 2025, the population of machine identities increased by 44%
AI agents are the fastest-growing category of NHI. Gartner predicts: 33% of enterprise applications will contain agentic AI by 2028 (in 2024 - less than 1%). Microsoft Copilot Studio has already transshipped a million created agents. At the same time, according to the CSA, more than 16% of organizations do not track the creation of identities associated with AI, and 85% are unsure of their ability to prevent an attack through the NHI.
For SOC teams, this is a specific headache: an AI agent is not a deterministic bot that drives the same lap. He decides in runtime, what APIs to call, in what sequence and with what parameters. Try to build a baseline on that.
CSA in its whitepaper formulates exactly: AI agents "accutings dynamically at runtime, spawn sub-gas, external APIs, write and execution code, and chains together disks that can of span"“Get permissions dynamically during execution, run subagents, call external APIs, write and execute code, and combine actions that can cover dozens of systems.”. Standard IAM processes confined to human accounts are not ready for this. And frankly, they won't be here soon.
Anatomy of attack: from the compromise of the token agent to the lateral movement
Attack path with a mapping on MITRE ATT&CK
Let’s look at the typical vector that I have observed in variations on multiple machine-to-machine authentication audits in LLM pypalines.
Phase 1 - Initial Access. The attacker exploits Prompt Injection (LLM01:2025 by OWASP Top 10 for LLM Applications). Through user input or a poisoned document in the RAG-pipeline, the agent receives instructions that changes his logic. In the context of NHI’s security in AI agents, it’s not a jailbreak for a “ridiculous response” – it’s the use of a legitimate credentials agent for illegitimate action. MITRE ATT&CK: T1078 (Valid Accounts). The agent acts on behalf of his service account, and from the point of view of IAM everything looks clean.
Phase 2 - Credential Access. The agent stores tokens to contact external services. In multi-agent systems (AutoGen, CrewAI), each sub-agent can hold its own set of credentials transmitted through shared memory or variable environments. MITRE ATT&CK: T1528 (Steal Application Access Token) - extraction of tokens from the memory module. If the agent is running on EC2/GCE without IMDS limitation T1552.005 (Cloud Instance Metadata API) gives temporary credentials through one HTTP request.
Specific script: LangChain-agent with access to Vault via AppRole. If secret_id According to the GitGuardian State of Secrets Sprav, in 2024, 23.77 million secrets flowed to public GitHub), prompt injection allows the agent to request an arbitrary secret from Vault. Vault has nothing to do with it - the excess rights of the NHI agent are vulnerable.
Phase 3 - Lateral Movement and Persistence. The received tokens are used to access related services: T1550.001 (Application Access Token). If the AI agent token contains the rights iam:AttachRolePolicy or analogues in Azure/GCP - the attacker fixes the persistence through T1098.003 (Additional Cloud Roles). In one of the AI-a-agent with rights to the Terraform state file could modify IAM-politics via IaC-pipeline - persistence without directly contacting the IAM API. Elegant if it wasn't so scary.
Insider threat: when a legitimate agent becomes an insider
Compromising LLM service accounts is essentially an insider threat. The compromised AI agent acts from its Valid NHI, with valid credentials, from the expected subnet. For SIEM, it looks like a legitimate process. Unlike an external attacker with a stolen password, there is no anomalous login, there is no impossible travel, there is no bruteforce - only an unusual set of API-chains. And if the baseline agent is already unstable because of undetermined nature - the anomaly drowns in noise.
According to Verizon DBIR, the stolen credentials is the most common initial access vector: 22% of all incidents. SpyCloud (Annual Identity Exposure Report) records millions of leaked API keys and tokens annually. For AI-related secrets (keys to the AI API, configuration currents of agents) growth was 81% for the year - the fastest among all categories of credentials, according to GitGuardian.
Tokens with excessive rights in LLM-PIplays
Overprivileged access - problem number two after the leak of secrets on OWASP NHI Top 10. For AI agents, it is even sharper: the developer gives the agent the maximum rights in prototyping, and the narrowing of the scope is postponed. Forever.
One token for all tool-calls. LLM agent via MCP (Model Context Protocol) or calling function accesses 5-7 services. Instead of individual credentials for each - one service account with all permissions. If one tool is compromised, blast radius covers all the others.
Long-lived credentials without rotation. NHI AI agents, by definition, "don't log out, can't use MFA, and are retired longed""does not leave the system, can not use multi-factor authentication and rarely leave" (Veeam). On one of the audits, I found the AWS access key for the SageMaker agent, which did not change 14 months - with the recommended rotation of 90 days. Fourteen months. For sale.
Orphaned identities. Data science team tests 10 variants of agents, each creates a service account. 8 agents are discarded, accounts remain active without a owner. Privileged access of machine identifiers to food resources - without the person responsible for their lifecycle.
Here is the minimum IAM policy limiting the scope of the LLM agent for RAG:
JSON:
{
"Version": "2012-10-17",
"Statement": [
{"Effect": "Allow", "Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::rag-docs-prod/*"},
{"Effect": "Allow", "Action": ["bedrock:InvokeModel"],
"Resource": "arn:aws:bedrock:us-east-1:*:model/anthropic.claude-*"}
]
}
According to the documents, the developer writes "scope will be minimal." In practice, most of the configurations I have tested is "Action": "s3:" or "Action": "". Guess which option is more common.
Detection-checklist: Correlation rules for NHI in SIEM
What to Monitor: Specific Alerates
For SOC commands working with API security tokens in AI systems, the following is a correctional ruler checklist. Each rule is tied to a specific TTP.
1. Anomalous API call pattern - the agent calls the API out of baseline (for example, iam:CreateUserwith the usual s3:GetObject) Indicator prompt injection through NHI. Related to T1078.
2. Credential usage from the unexpected source of the agent is used from an IP that does not match the VPC/deployment subnet. T1550.001.
3. Token usage outless execution window - for agents with a cron-schedule any activity outside the execution window - altrate.
4. Spike in API call volume - a sharp increase in the number of calls indicates data exfiltration or a selection of resources. T1528.
5. Access to secrets stores - an agent for Vault, Secrets Manager or Parameter Store outside the casino line. T1552.005.
6. Cross-account access - NHI agent accesses resources in someone else's account / project. T1550.001.
7. Annomalous role - the agent takes the role (AssumeRole), which has not been used before. T1548.005 (Temporary Elevated Cloud Access).
Example of Sigma-like rule for detection of anomalous AssumeRole:
YAML:
title: AI Agent NHI - Anomalous Role Assumption
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventName: AssumeRole
userIdentity.type: AssumedRole
userAgent|contains: 'langchain'
filter:
requestParameters.roleArn|endswith:
- 'rag-reader-role'
condition: selection and not filter
level: high
Building a baseline for undetermined agents
For a deterministic service account, baseline is built in 14-30 days on a fixed set of API-calls. With AI agents, this approach breaks down – their behavior depends on user samples, and two identical queries can give rise to completely different chains of calls.
The work scheme that I ran through several projects:
• Limit the set of available tools at the MCP server config (Kifiable function confa) is the top boundary of baseline
• Log in each tool-call with metadata: which tool, parameters, initiated by the user or automatically
• Build baseline by category: read / write an admin, not on specific calls
• Any action of the admin category from NHI agent is analt without exception. No options.
Least privilege for autonomous systems - practical checklist
Adjustments to the environment
The cheat sheet is applicable to AI-agents in:
• AWS : IAM + Bedrock/SageMaker, STS for short-lived tokens
• Azure : Managed Identities + OpenAI Service
• GCP : Service Accounts + Vertex AI, Workload Identity Federation
• On-premise : HashiCorp Vault 1.15+ for secrets, SPIFFE/SPIRE 1.9+ for machine identity
• Hybrid : cloud LLM + on-prem data sources via VPC peering
