Zero Trust AI Assessment Framework

This framework is for security architects and platform teams running LLM applications, AI agents, model-serving endpoints, or training pipelines. Zero trust, as defined in NIST SP 800-207, removes implicit trust based on network location: every request is authenticated, authorized, and continuously evaluated. AI workloads stress that model because agents act on behalf of users, chain tool calls together, and touch many data sources in a single task.

Use it before an AI system goes to production, when an agent gains new tools or data access, and as an annual maturity review.

How to use this framework

1. Score each item 0 (not in place), 1 (partial or manual), or 2 (enforced and monitored).
2. Roll scores up by section. The sections follow the pillars of the CISA Zero Trust Maturity Model (identity, devices, networks, applications and workloads, data), so you can report progress in the same language.
3. Turn the lowest-scoring section into your next-quarter roadmap rather than trying to fix everything at once.

Identity and access

• □ Every AI agent and model service has its own unique workload identity. Shared identities make attribution and revocation impossible.
• □ Agents acting for a user carry delegated, scoped tokens rather than a broad service account, so an agent can never do more than the user it serves.
• □ Access is granted just-in-time per task or session and expires automatically.
• □ Policy decisions use context: identity, workload attestation, data classification, requested action, and time.
• □ Credentials are short-lived. Where static secrets remain, they are vaulted and rotated on a defined schedule.
• □ High-impact actions require human approval (payments, deletions, external sends, permission changes).

Data protection

• □ Training data, vector stores, prompts, and outputs are classified like any other data store.
• □ Retrieval enforces the requesting user's permissions at query time. A vector index must not become a way around document access controls.
• □ Agents receive the minimum data necessary; sensitive fields are masked or tokenized before reaching the model.
• □ Outputs are filtered for sensitive data before they leave the trust boundary.
• □ Encryption is enforced in transit and at rest, including model artifacts and embeddings.
• □ Model weights and artifacts are integrity-checked (signed or hash-verified) before loading. A tampered model is a supply chain compromise.

Network and workload

• □ AI workloads run in segmented environments with default-deny egress and an allow-list of model endpoints and tools.
• □ Service-to-service connections use mutual TLS bound to workload identities.
• □ East-west traffic between agents, tools, and data stores is logged.
• □ New external tools or APIs require explicit approval before an agent can call them.
• □ Code-execution tools run in isolated sandboxes with no standing credentials.

Monitoring and response

• □ Every prompt, tool call, and data access is logged with both the agent identity and the delegating user.
• □ Behavioral baselines exist per agent, with alerts on new tools, volume spikes, or unusual data access.
• □ A tested kill switch can revoke an agent's credentials and halt it within minutes.
• □ Agents are red-teamed for prompt injection and excessive agency on a regular cadence.

Common pitfalls

• Treating the model gateway as the only control point. Most risk sits in the tools and data the agent can reach.
• Giving an agent the union of all its users' permissions. This creates a confused deputy that any user can exploit.
• Network-only zero trust. Microsegmentation does little if the agent authenticates with a shared API key.
• Logs without identity context. Prompt logs you cannot tie to a user and agent are useless during an investigation.