Field Notes · DevSecOps · Agentic AI

Zero Trust for Agentic AI: Managing Non-Human Identities at Scale

Your AI agents are employees now — untrained, tireless, and holding more credentials than your entire human workforce. Field notes on the new threat surface, a supply-chain attack that never touches your code, and the identity-first playbook that closes the gap.

Twice in the same week, the same message arrived from two very different rooms. In one, a Sr. Director of DevOps at a NYC ad-tech platform described the two things he needs a DevSecOps leader to own: AI security and a shift-left strategy for CI/CD — including the security foundation for a greenfield GPU cluster. In the other, a joint IBM (HashiCorp) and AWS session on zero trust for agentic AI laid out exactly why those two mandates are now the same job. This page is my synthesis of both: what the threat landscape actually looks like, and where I'd start.

The core problem has a name: non-human identity (NHI) sprawl. Every agent, service account, API key, and machine credential is an identity — and they now outnumber the humans by an order of magnitude, with more privilege and less oversight.

50:1
Non-human identities outnumber human identities — and the ratio is growing
80%
of breaches involve non-human identities
>35%
of documented AI incidents are prompt-based exploits — the #1 failure type
$100K+
typical loss triggered by basic prompt injection — before reputational damage

Figures cited in "Zero Trust for Agentic AI" (IBM/HashiCorp + AWS, Aug 2026). Most orgs still have no offboarding process for API keys.

Déjà vu: prompt injection is SQL injection with a new actor

Twenty years ago the industry's #1 vulnerability was a parsing failure — little Bobby Tables and the unparameterized query. We fixed it with input validation and parameterized SQL, and it fell down the charts. Prompt injection is the same lesson returning with a different actor. Except this time the "query engine" is autonomous: it makes independent decisions, it adapts its behavior continuously, and it holds credentials to your email, your documents, your databases, and your cloud accounts.

The recent headlines are not exotic: 64 million McDonald's job applications exposed behind a 123456 password on an AI hiring platform; Samsung source code pasted into a public chatbot; 480,000 patient records leaked from an Elasticsearch instance that sat open for six weeks; a dealership chatbot talked into "selling" a $76,000 Tahoe for $1; and EchoLeak — the first zero-click AI vulnerability — exfiltrating data from Microsoft 365 Copilot via plain text in ordinary business documents. No code execution required. The attack surface is language itself.

Fig. 1 — Anatomy of an agentic system, with its attack surface

Userhuman intent
App / Sitefront door
Routerorchestration
Agentsautonomous, multi-agent
Tools / MCPemail · docs · APIs
ServicesDBs · cloud · SaaS
Every hop is a trust boundary, and every tool an agent can reach is a new entry point. Autonomy means the controls must live in the system — there is no human in the loop to catch the drift.

The threat taxonomy: four categories to plan against

Identity & Access Control

  • Confused deputy — a high-privilege service acts for a low-privilege user without enforcing identity boundaries. If the human can only read, the agent must not write.
  • Credential & secret sprawl — long-lived, hard-coded, unrotated credentials in unsecured locations. Every org has them; the only variables are how many and how exposed.

Integration & Supply Chain

  • Tool poisoning — malicious instructions embedded in tool metadata trick agents into unauthorized actions and exfiltration.
  • MCP registry attacks — malicious servers submitted to, or trusted entries redirected in, Model Context Protocol registries.
  • Multi-agent communication poisoning — tampering with the messages controller and worker agents exchange.

Runtime & Data Security

  • Direct prompt injection — crafted input overrides agent instructions.
  • RAG poisoning — malicious data planted in the knowledge bases retrieval-augmented generation trusts.
  • Tool misuse & guardrail evasion — agents coaxed into calling tools with the wrong credentials; multi-modal payloads (text, audio, image) that slip past detection. Adversarial text alone can do it — no code involved.

Compliance & Governance

  • Insufficient audit trails — the gap that turns an incident into a crisis. Without logging of prompts, conversations, and secret access, you cannot trace an agent action back to an authorizing human — or satisfy a regulator.

The cautionary tale: the attack that never touches your code

The most instructive part of the session was a demo of a supply-chain attack aimed not at an application, but at the development process. A developer asks a coding agent to add a live-weather endpoint to an MCP server, dutifully following the team's mandated best-practices documentation. The agent reads the docs, writes the code, tests pass, manifests generate, ship it. Functional. Correct-looking. Compromised.

Fig. 2 — Poisoned-context supply-chain attack, step by step

Attacker compromises the team's "best practices" docs

Not the source code — the context. The docs (served via MCP, a wiki, or files in the repo) now recommend a typosquatted request library from a "private repo" and note that it "requires" hostNetwork: true in Kubernetes manifests.

Developer prompts the coding agent

"Add a live-weather feature to the MCP server." The agent reads the code — and the poisoned best practices — exactly as instructed by team policy.

Agent generates plausible, working code

from request import get slides past review. The Kubernetes manifest gets hostNetwork: true with a helpful generated comment. The developer, moving at vibe-coding speed, YOLO-approves each step and pastes a live API key into config "just for testing."

Tests pass — ship it

The app works against the live API. Dockerfile and deployment manifests generate with minimal intervention. Functional correctness ≠ security.

In production, the malicious library activates a packet sniffer

With host-network access, it sees traffic from every workload on the node — not just the innocuous weather app.

Credentials harvested from an unrelated, sensibly-coded system

A different agentic app queries Postgres in cleartext; MD5-hashed credentials are captured, cracked in no time, and exfiltrated. Read-write creds, long-lived, untraceable to any human. Game over.

The zero-click pattern applied to the SDLC: the attacker manipulates what the agent trusts, and the agent does the rest. Root causes: no TLS on "back-end" traffic, no attribution, long-lived over-permissive credentials, unscanned context.

The cognitive failure modes matter as much as the technical ones: speed over scrutiny (we trust the agent as a peer, so peer review erodes), invisible dependencies (over-permissive MCP servers nobody audits), and a supply chain — context files, knowledge bases, tool metadata — that simply doesn't exist in a classic SDLC threat model.

Shift left, for real this time

The agentic development lifecycle mirrors the classic SDLC — but the "developer" is now partly an agent, and the controls have to move upstream to where the agent forms its beliefs. If the attack above had hit any of the guardrails below, it dies before production.

Fig. 3 — Agent development lifecycle with shift-left controls

Planthreat-model the agent · scoping matrix
Code & Buildsandbox agents · scan context & deps
Test & Releaseevals · IaC linting · red teaming
DeploymTLS · ephemeral creds · least privilege
Operate & Monitoraudit trails · OTel attribution
security investment shifts left
Sandboxing what coding agents can reach, scanning the context they consume (best-practices docs, MCP metadata) as seriously as code, and linting manifests for privilege escalators like hostNetwork: true are pipeline problems — not production problems.

A mental model for how much to trust an agent

AWS's Agentic AI Security Scoping Matrix is the most useful classification tool I've seen for this: place each use case on a spectrum of agency, then tune six security dimensions to match. The discipline it enforces is sequencing — policies and procedures first, identity second, and only then application and data protection. If you haven't defined it, you can't build an identity policy around it. Retrofitting is always more expensive.

Fig. 4 — Agentic AI security scoping: agency vs. control

Scope 1 · No Agency
Human initiated, agentic change prohibitedAgents follow a defined path with no ability to execute change. Agent finds the meeting time; the user books it.
Scope 2 · Prescribed
Human approved agentic actionsAgents execute change with human-in-the-loop initiation, review, and approval. Agent books after human review.
Scope 3 · Supervised
Human initiated, automated actionsHuman-triggered workflows with autonomous agentic actions. Agent books the meeting automatically.
Scope 4 · Full Agency
Automated initiation & actionSelf-initiating AI with autonomous agentic actions. The environment triggers the agent; no human in the loop.
less agency + risk
more
Critical security dimensions (tuned per scope): identity context (authN + authZ) · data, memory & state protection · audit & logging · agent & foundation-model controls · agency perimeters & policies · orchestration
Adapted from the AWS Agentic AI Security Scoping Matrix. Layer on org-wide boundaries — SCPs/RCPs as permission guardrails, IAM condition keys that distinguish AI-driven from human-driven requests, and foundation-model guardrails (Bedrock) that filter what agents can even ask.

The identity answer: broker everything, trust nothing for long

If there's one architectural conviction the session reinforced, it's this: assume credentials will leak, and make the leak worthless. That means every agent gets a unique, auditable identity; every action traces to an authorizing human where one exists; authorization is dynamic (token exchange, ephemeral credentials); and permissions are explicit, time-bound, and revocable. Static secrets in config files are how the demo attack cashed out — short-lived brokered credentials are how it would have been neutralized.

Fig. 5 — Identity brokering & dynamic credentials for humans and agents

Humanauthenticates via IdP (Okta / Ping)
out-of-band approval on device
Agentown identity — entity + aliases
OAuth scope from delegation
authN
+ policy
Identity Broker / Vaultentity per identity (human or NHI) · policies mapped at auth time · token with TTL, session & delegation claims · mints just-in-time credentials · every action audit-logged
ephemeral
creds · mTLS
Databasesdynamic creds, minutes-long TTL
Cloud / K8s / APIsPKI · SPIFFE workload identity · certs auto-rotated
Audit spine: broker logs + CloudTrail + OpenTelemetry traces → every action answers "which agent, on whose authority, at what cost?"
The pattern generalizes across HashiCorp Vault (entities, dynamic secrets, PKI/SPIFFE, Secrets Operator for Kubernetes), IBM Verify (OAuth + out-of-band consent, JWTs with TTL and revocation), and AWS AgentCore Identity + Cedar policies. Separate the human's identity from the agent's, and let delegation — not shared credentials — connect them.

Where I'd start: a practitioner's playbook

The webinar closed by asking attendees to take one practical step back to their organization. Here are the five I'd take — the same five I'd apply to a greenfield GPU cluster buildout, where you get exactly one chance to make these defaults instead of retrofits.

Inventory your non-human identities

Assume 50:1 and over-privileged until proven otherwise. Find the long-lived credentials — hard-coded, unrotated, unowned — and vault or kill them. Build the API-key offboarding process most orgs don't have.

Make credentials ephemeral where the blast radius is biggest

Databases and cloud-provider credentials first. Minutes-long TTLs, automatic revocation, brokered issuance. A leaked credential that expired an hour ago is a non-event.

Encrypt the traffic you were sure was "internal"

The demo's packet sniffer worked because back-end traffic ran cleartext with MD5-hashed passwords. mTLS everywhere, PKI automated through the broker, SPIFFE for workload identity. On a greenfield cluster this is a day-one default, not a migration.

Shift agent security into the pipeline

Sandbox coding agents and scope what they can reach. Scan the context they consume — best-practices docs, MCP tool metadata, knowledge bases — with the same rigor as dependencies. Lint IaC for privilege escalators. Separate human identities from agent identities in every system, with explicit delegation between them.

Instrument attribution end-to-end

OpenTelemetry traces plus broker and cloud audit logs, one schema, flowing to your SIEM. Every agent action should answer three questions: which agent, on whose authority, and at what cost? If you can't answer them, you don't have an audit trail — you have a liability.

Takeaways

QuestionAnswer
What's different now?The non-deterministic, autonomous nature of agents — and an NHI population growing faster than any governance process. Security controls must be baked in; there is no human overseer to catch drift.
What's the same?Almost everything else. Least privilege, TLS, secrets management, audit logging — the fundamentals still apply. The gap isn't knowledge; it's enforcement and automation at agentic speed and scale.
What's needed next?Plan for the capabilities still maturing — AI-native red teaming, prompt filtering, model-version governance, shadow-model detection — so you can adopt them the moment they're ready.

The two mandates from that conversation — owning AI security and shifting CI/CD security left — aren't parallel workstreams. They're one discipline: treat every agent as an identity, every piece of context as supply chain, and every action as something you must be able to attribute. That's zero trust for agentic AI, and the organizations that internalize it now will be the ones that never make the headlines that opened this piece.