Your AI Agent Is a Cloud Identity. Its Permissions Are Only Half the Story

The newest privileged employee in your cloud directory may not be an employee at all.

AI agents now open tickets, change code, call APIs, query data stores and operate cloud services. To do any of that, they need an identity: a service account, workload role, API token or delegated user session. Security teams know how to authenticate those principals and assign permissions. The uncomfortable part comes afterwards.

A valid identity can still take the wrong action.

On 14 September 2026, Unit 42 published research on mapping cloud identities from their observed behaviour rather than relying on names or assigned policies. The researchers examined more than 40,000 identities across 125 cloud environments over two months. Their opening problem statement explicitly includes human, machine and autonomous-agent identities.

The research is not a study of AI agents specifically, and it should not be presented as one. Its central distinction nevertheless lands directly on agent security:

• Permissions describe what an identity can do.
• Audit activity shows what that identity actually does.

For an AI agent, a third question matters just as much:

• What context caused it to try?

That is the security boundary most agent deployments still leave to optimism.

1. Meet the newest non-human identity

A useful agent cannot remain a text box. It needs authority.

A coding agent may read repositories, create branches, invoke CI jobs and publish artefacts. A finance agent may inspect invoices, update a ledger and prepare payments. An operations agent may query production, restart a service or alter infrastructure. Each capability eventually becomes a credential and a set of permissions.

The usual advice is least privilege. It remains correct, but it is no longer a complete answer.

Authentication establishes which principal made a request. Authorisation establishes whether that principal was permitted to make it. Neither establishes that the action matched the human operator’s intent. An agent can be correctly authenticated, remain inside its policy envelope and still do harm because its reasoning was steered by hostile content, stale context or a poisoned tool description.

That creates a dangerous category of event: the wrong authorised action.

Imagine a support agent with legitimate permission to issue refunds up to a fixed value. A malicious instruction hidden in a customer-supplied document convinces it that several fabricated claims satisfy policy. Every API call is authenticated. Every refund remains below the limit. A conventional access log records successful use by an approved identity.

Nothing about that log, by itself, says the model was manipulated.

Agent identity therefore needs more than a principal and a policy document. It needs evidence of normal behaviour, trustworthy context provenance and a control outside the model that decides whether proposed actions may proceed.

2. Permissions tell only half the story

Unit 42’s research starts with a familiar cloud problem: identity names and IAM assignments are poor descriptions of real function.

A role may be called backup-service while holding broad administrative permissions. A security scanner may enumerate thousands of resources as part of its normal job. Another service identity performing the same enumeration may be compromised. The operation is identical; the behavioural context is not.

The researchers used activity patterns from AWS CloudTrail to group identities by the operations they invoked. Across the wider dataset, those patterns formed recognisable functional clusters, including administration, DevOps, security and CI/CD roles. The article describes how those clusters can be converted into lighter-weight classification logic, including standard SQL, rather than requiring a heavyweight machine-learning pipeline to run continuously.

The architectural lesson is more important than the clustering technique: observe the identity as it behaves.

For an agent workload, establish a narrow baseline:

• Which services does it normally call?
• Which tools does it invoke, and in what sequence?
• Which resources and regions does it touch?
• How often does it request credentials or change permissions?
• What volume of reads, writes or exports is normal?
• Does its behaviour change after processing a particular external source?

A broad service account called assistant-prod tells a responder almost nothing. A dedicated identity with a small permission set and a clear behavioural history tells them far more.

This is why shared credentials are especially corrosive. If five agents, three workflows and two humans all use the same principal, unusual behaviour cannot be attributed cleanly. Rotation becomes disruptive, containment becomes guesswork and an audit trail becomes a group photograph of suspects wearing the same coat.

Give each agent or tightly bounded service its own identity wherever the platform allows it. Scope it to the task. Make delegation visible. Then monitor what that identity actually does.

3. Prompt injection can borrow legitimate authority

Prompt injection is often described as an input-validation problem. That framing is too small once an agent has tools.

The attacker does not necessarily need to steal a credential. It may be enough to influence the process already holding one.

Microsoft’s September guidance on securing edge AI states the assumption plainly: prompt injection will occur. It also notes that trusted data is not necessarily safe data. A signature may prove where a document came from; it does not prove that the document is safe for an AI system to interpret as context.

That distinction applies well beyond edge deployments. Email, web pages, issue descriptions, retrieved documents, MCP tool descriptions, memory entries and another agent’s output can all shape model behaviour. A legitimate source can carry hostile instructions. A clean runtime can load a poisoned artefact. An authorised tool can receive a dangerous argument.

Once the model proposes an action, asking the same model whether the action is safe is not an independent control. It is the same uncertain component reviewing its own uncertain output.

Microsoft recommends a deterministic mediator outside the model. The model may recommend an action; the mediator decides whether to authorise it. That layer can allowlist operations, constrain arguments, limit frequency and release credentials only when policy permits. High-consequence or irreversible actions still need an independent approval, interlock or fail-safe path.

This is the missing bridge between identity and intent.

Cloud IAM can say, “this agent may update a customer record”. A mediator can say, “it may update these fields, for this tenant, at this rate, but it may not replace the payment destination without approval”. Behavioural monitoring can then say, “this identity has never attempted fifty such changes after reading one uploaded document”. Provenance can point investigators back to the context that preceded the attempt.

Each layer answers a different question. Collapsing them into one allowed: true is how incidents become technically authorised.

4. Build the agent identity boundary properly

A defensible agent architecture does not require clairvoyance. It requires several ordinary controls applied without pretending the model is a trusted decision-maker.

Use one workload identity per agent or bounded service. Avoid shared API keys and inherited human sessions. Separate identities improve least privilege, attribution, rotation and containment.

Prefer short-lived, task-scoped credentials. Do not place standing cloud keys in prompts, memory stores or general-purpose tool configuration. Release a credential only for the approved operation and lifetime.

Put deterministic mediation outside the model. Allowlist actions, validate arguments against typed schemas, restrict destinations, cap frequency and require approval when an action is expensive, destructive, externally visible or difficult to reverse.

Preserve audit evidence outside the agent’s control. Record identity, proposed action, policy decision, tool result and relevant provenance in a system the workload cannot quietly rewrite. Logs stored beside the agent are souvenirs, not evidence.

Baseline behaviour, then alert on meaningful change. A new API family, sudden enumeration, unusual export volume, credential discovery or repeated denied actions can be more informative than a static identity name. Build baselines around function, not wishful labels.

Track the artefacts that shape behaviour. Agent definitions, retrieval indexes, memory entries, tool descriptors, policies and updates all influence decisions. Record origin and integrity. Attestation can establish trust in the runtime; provenance can establish where an artefact came from. One does not replace the other.

Keep humans at irreversible boundaries. Payments, production deletion, privilege changes, public communication and release of sensitive data should not become safe merely because a model produced valid JSON.

None of these controls guarantees that every permitted action is wise. They make authority narrow, evidence visible and mistakes containable. That is the job.

5. Where ShieldCortex fits — and where it does not

ShieldCortex does not replace IAM, CloudTrail, cloud detection and response, workload isolation or a human approval system. It should not be sold as behavioural anomaly detection or as a universal gate around every tool used by every agent.

Its architectural fit is the context boundary.

Traditional identity systems answer who the agent is and what permissions it holds. Cloud telemetry records what the identity did. ShieldCortex is concerned with untrusted content and agent context at explicit integration points: the material that can shape what the agent believes, retains or proposes to do.

On bound hosts that is a write scan on native memory and a tool gate where the host actually lets us deny. Action Guard stays off by default. Automatic memory inject stays off. Native OpenClaw, Hermes and Claude memory stays the brain. We sit on the door. We do not claim CloudTrail clustering, and we do not claim that every prompt injection is preventable.

That narrower scope matters because an identity-only view cannot explain why a valid principal suddenly attempted a dangerous but permitted operation. Preserving source and context signals alongside action-policy decisions gives operators a better chain of evidence: which identity acted, what it attempted, what context influenced it and which independent control allowed or denied the effect.

The complete design is layered:

• IAM limits authority.
• Short-lived credentials limit exposure.
• Runtime isolation limits reach.
• Deterministic mediation limits actions.
• External audit and behavioural analysis expose deviations.
• Context integrity and provenance help trace influence.
• Human approval protects consequential boundaries.

AI agents are now cloud identities. Treating them like ordinary service accounts is a good start. Treating their assigned permissions as the whole security model is not.

The permission policy tells you what the agent can do. Secure operation begins when you can also explain what it did — and why.

Sources

• Unit 42 — Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection (14 September 2026)
• Microsoft Security — How to secure edge AI in customer-owned environments (4 September 2026)