The CISO Zero-Trust AI Checklist From Runtime Isolation to Vendor Access Attestation

A zero-trust AI architecture for enterprise must contain compromised agents. That requires five connected control domains, including runtime isolation, prompt containment, agent identity, vendor access attestation, and supply chain integrity. Preventing vendor access to internal prompts also requires an enforced execution boundary.

Why traditional Zero Trust fails when instruction and data share the same channel

An LLM gets system instructions, user messages, and retrieved documents in a single token sequence made up of role-tagged messages. Those roles describe authority, but they do not create a runtime boundary between instructions and content. A retrieved document can therefore become an instruction channel. Instruction-data collapse extends beyond misconfiguration that an access review can correct.

OWASP’s agentic risk taxonomy places Agent Goal Hijack, ASI01, at the top of its risks and identifies this collapse as a structural cause. For an agent, the consequences extend beyond a misleading answer because its tools may allow it to delete files, modify IAM policies, or query production databases. The access can be legitimate while the action is malicious. What does authentication establish when an authorized agent follows an attacker’s instructions?

Persistent memory makes that question harder. A poisoned entry planted today can affect an unrelated query next week, even with session isolation in place. Autonomous identities then execute those instructions with credentials and lateral API access at machine speed. The governing principle is containment over prevention, because no defense fully stops prompt injection.

The non-human identity explosion and why existing IAM frameworks cannot govern it

Non-human identities, including service accounts, bots, and AI agents, vastly outnumber human identities in enterprise environments. Most have more privilege than their function requires, while a majority of their credentials are not rotated within recommended timeframes. The imbalance is already a governance emergency. An identity program organized around human access reviews cannot adequately govern a much larger population acting autonomously.

Delegation makes the gap concrete. When a developer runs coding agents overnight using the developer’s credentials, those agents inherit the systems and permissions available to that person. Current IAM and audit tools can leave their actions unrecorded as distinct agent activity. Shadow AI compounds the problem because agents deployed without security approval become hidden channels for data leakage.

The CISA/Five Eyes “Careful Adoption of Agentic AI Services” guidance treats distinct agent identity as a requirement. The guidance was dated April 30, 2026, and publicly released May 1, 2026. Its position is that each agent needs a cryptographically anchored key or certificate, short-lived credentials, and encrypted communications. That establishes the governance unit as the agent itself.

The checklist gap CISOs are already carrying: what current programs miss

Security leaders’ confidence in AI defenses coexists with widespread AI-related incidents and weak containment capabilities. Traditional programs look at patch cycles, access reviews, and vendor questionnaires. Those checks do not establish whether an agent’s runtime permissions match its intended purpose or whether manipulated content can redirect its actions. The missing test is behavioral and operational.

Most organizations cannot enforce purpose limitations, quickly stop a misbehaving agent, or keep AI systems from reaching the broader network. Only a small minority say their AI governance meets their needs, and even fewer have full security approval for every agent they have deployed. Teleport’s research found much lower incident rates in organizations that enforce least-privilege access for agents than in those that do not. That finding points to an architectural decision.

The checklist addresses an existing gap. Its five domains are runtime isolation, prompt containment, agent identity, vendor access attestation, and agentic supply chain integrity. Each addresses a different point where an authorized system can exceed its intended bounds.

Runtime isolation: the difference between observability and enforcement

Runtime telemetry shows what an agent is doing. Enforcement can stop it. eBPF-based telemetry and behavioral analytics can generate alerts, while kernel-level inline blocking through eBPF and Linux Security Modules can prevent execution. A SIEM cannot substitute for that blocking when an attack completes before a person can respond.

For CISOs, the operational requirement is kernel-level enforcement for AI workload containers. Monitoring must cover agent-to-agent traffic within serverless runtimes as well as provide network-layer visibility. This coverage question includes agent exchanges that traverse the network. Which interactions can the deployed controls actually observe and stop?

Sensitive inference introduces a separate isolation requirement. In a hardware-enclave architecture, remote attestation provides evidence of enclave integrity before a Key Broker Service releases the decryption key into protected memory. Container isolation does not provide the same boundary against inspection by the host OS, hypervisor, or cloud provider administrators. For high-sensitivity workloads, the checklist should require attestation before key release, because execution blocking and protection from infrastructure operators solve different problems.

Prompt injection containment and the model gateway as enforcement plane

A model gateway moves enforcement to the inference-request layer, where prompt content and model output are available for inspection. Its control surfaces are identity, data, model, and output. Every request must pass through prompt filtering and rate limiting, and every output must pass validation before triggering downstream action. Logging alone leaves the action path open.

EchoLeak, CVE-2025-32711, illustrates why that distinction is consequential. Indirect prompt injection compromised the model through an LLM Scope Violation, and because there was no output validation, the compromised output could trigger downstream data exfiltration. Filtering has limits and model output cannot authorize its own consequences.

The checklist therefore pairs a gateway with AI-specific microsegmentation. The RAG vector database cannot initiate arbitrary outbound connections, the orchestration service can reach only defined tool endpoints, and the inference container is isolated from workloads other than the API gateway. These boundaries limit what a redirected model can reach. Gateway controls must also extend to dynamically registered MCP tools and A2A channels, with output validation remaining a hard gate before tool calls.

Agent identity governance: per-agent credentials, just-in-time access, and kill-switch readiness

Teleport’s least-privilege finding gives this domain particular weight. Its sharply lower incident rate among organizations enforcing restricted agent access supports treating credentials as a containment control. Each agent instance needs a distinct principal and its own cryptographically anchored credential. When agents share service-account tokens, they lose that separation, and the secret exposes the combined access of every agent that uses it.

Permissions should be granted only when needed and revoked automatically after the task. Maximum token lifetimes should be enforced at credential issuance, measured in minutes for high-privilege agents. Short lifetimes limit durable access after compromise. JIT grants and post-task revocation also need testing, because a written expiry policy does not demonstrate that access ends.

Termination is a separate capability. A tested kill switch must stop a misbehaving agent before it completes a lateral move, without waiting for a person to step in. Designers must also define human-approval thresholds for irreversible actions before deployment and enforce them at the orchestration layer. If the agent decides when its own actions need approval, that boundary relies on the very judgment being attacked.

Vendor access attestation: how do you prevent an AI vendor from seeing internal prompts and data?

The Vercel–Context.ai breach on April 19, 2026, shows how vendor access can become internal exposure. Attackers reached Vercel internal systems and a limited subset of customer credentials after Context.ai was compromised. A Vercel employee had granted the platform broad OAuth permissions over an enterprise Google Workspace account. Earlier, in February 2026, a Context.ai employee had been infected with Lumma Stealer through a personal download of Roblox “auto-farm” scripts.

The structural failure was excessive delegated trust. An “Allow All” grant provides maximum access upfront without a mechanism to dynamically revoke it when the vendor’s security posture changes. The checklist response is to replace those grants with scoped, revocable, time-limited permissions and audit existing grants before next quarter. The review must include fourth-party AI sub-processors because data can be exposed beyond the vendor the enterprise deals with directly.

Preventing a vendor from seeing prompts requires a different kind of evidence from promising not to retain them. Zero-retention and inference logging policies should be confirmed in writing, but those commitments do not establish an execution boundary. The architecture must establish where processing occurs and whether attested isolation keeps data protected during inference. A questionnaire cannot prove that property.

AI-specific due diligence must also check model provenance, how NHI practices are used, what certification covers, and whether incident response covers changes in behavior. Contracts should require an AI Bill of Materials, notices when the model changes, disclosure of sub-processors, and AI-specific response timelines that are separate from standard breach clauses. Governance claims need third-party auditor opinions, such as an ISO 42001 certificate or equivalent. For public-repository models, documented scanning and integrity verification are also necessary contractual deliverables, given the malicious models identified and removed from Hugging Face since 2024.

Agentic supply chain controls and the MCP/A2A trust boundary

Assessing a vendor does not establish whether components can still be trusted when they change during execution. MCP and A2A ecosystems allow runtime components to be added, modified, or replaced after deployment. A previously legitimate tool can therefore become a new exposure through a later registry update. Deployment approval is not permanent authorization.

The GitHub MCP exploit illustrates a related boundary problem. A prompt injection payload in a public GitHub Issue reached a running agent through a trusted issue-retrieval tool call, while the tool registration itself was not poisoned. The distinction is important because both retrieved content and registration events need controls, but they are different attack paths. Trust in a tool does not establish trust in everything it returns.

The checklist must also require gateway policy validation at registration events, keep a dynamic tool inventory, and require cryptographic integrity verification of tool manifests when they are registered. Third-party tool sources also need the vendor attestation requirements already described. The guidance acknowledges that agentic security standards “are not yet covered by existing frameworks.” Organizations must extend their controls rather than wait for a framework to define every boundary.

What an honest gap assessment looks like: the objection that Zero Trust gives false confidence

The strongest objection is that Zero Trust language can overstate what these controls guarantee. A program can acquire the label while retaining broad credentials, unenforced approval thresholds, and telemetry that cannot block execution. The objection deserves a direct answer. Does the architecture limit what an agent can do, or does it only record evidence after the agent acts?

The guidance’s warning that systems “may behave unexpectedly” rules out presenting this checklist as a prevention guarantee. Prompt filtering cannot eliminate every injection, and monitoring cannot become enforcement through a change of terminology. Human-in-the-loop language also does little to protect a system if the agent itself decides when to bring in a person. These are substantive gaps.

For a board, the accurate claim is that the program is designed to contain compromise. A review should ask whether a compromised agent was stopped before it completed lateral movement and whether its access stayed within the intended boundary. Incident counts alone cannot answer those questions. Containment over prevention is the principle that makes the checklist defensible without making it complacent.

Assembling the checklist: a domain map CISOs can carry into a board conversation

The five domains give a program review a coherent structure without turning it into a product inventory. Runtime isolation concerns what can execute and who can inspect protected inference. Prompt containment governs what enters the model and what its output can trigger. Agent identity determines whose authority is exercised, for how long, and how quickly it can be withdrawn.

Vendor attestation applies those questions to vendors outside the enterprise. Supply chain integrity then follows them into tools and components that can change at runtime. These domains are connected but not interchangeable. An audited vendor does not remove the need for scoped credentials, and an attested enclave does not validate a model’s proposed tool call.

Privacy-preserving infrastructure shows why isolation and inference controls need to be designed together. For a budget conversation, that shifts attention from the number of security products to the boundaries they jointly enforce. The board-ready test is whether each incident’s reach stayed within those boundaries, including when action was faster than human intervention. The objective is not an agent that cannot be compromised, but an architecture that contains the damage when it is.