Skip to content
SecTepeMit Sicherheit gut aufgestellt!
DE
Glossary

Zero Trust for AI Systems and AI Agents

Zero trust for AI: how to limit and verify the access of AI agents and service accounts to data and tools, and how to protect model weights.

Definition: Zero trust is a security model built on the rule "never trust, always verify". No access is trusted just because of where it sits in the network or because of a one-off login. Every request is checked against identity, context and policy. For AI, this means you treat AI apps, agents and their service accounts as separate identities that you do not trust. Their access to data, tools and models is kept tight and checked all the time.

Core zero trust principles

NIST Special Publication 800-207 describes zero trust as an architecture built on three core ideas:

  • every access is checked on its own
  • rights are granted as narrowly and briefly as possible
  • you assume an attacker may already be inside the network

On the technical side, a policy decision point rules on each request. A policy enforcement point then applies that decision.

Why AI systems are a special case

Classic apps follow fixed code. AI apps are different, above all language models with tool access. They decide at runtime which data to query and which actions to take. Inputs steer these choices, and some of those inputs come from outside. This leads to typical risks:

  • Prompt injection: a crafted email, web page or document tricks an AI agent into passing on data or taking actions nobody wanted. You cannot reliably harden the model itself against this. So rights must limit the damage.
  • Excessive agency: the OWASP Top 10 for LLM Applications lists "Excessive Agency" as a risk of its own. Agents get more rights, tools or freedom than their task needs.
  • Service accounts with too many rights: an intranet AI assistant often runs under a technical account that can read every document. Any user can then see, through the assistant, content they could not open themselves.
  • Model weights as crown jewels: models you have trained or fine-tuned are valuable intellectual property. They can also leak training data. If they sit unprotected on a file server or in an open storage bucket, someone can copy or tamper with them.

Putting zero trust into practice for AI

A separate identity for every AI part

Each agent and AI app gets its own identity that you can clearly trace, not a shared API key. Credentials should be short-lived and renew on their own. Workload identities on the cloud platform or short-lived tokens can do this. Avoid static keys in source code or config files.

Acting on behalf of the user

Say an AI assistant accesses company data, for example with retrieval-augmented generation (RAG). Then the query should run with the rights of the user who asked. Check rights at query time, not only when documents are added to the index. That way the assistant can only return what the user may already see.

Authorise each tool call

An agent may send an email, change a record or start a payment. Every such tool call passes through a policy check outside the model. You can approve read-only actions more freely than write actions. Actions with serious effects need a human to confirm them. The same goes for standard links such as the Model Context Protocol (MCP): every connected server is a trust boundary.

Control the network and data leaving it

AI workloads should only be able to talk to the systems they really need. Outbound links are limited to approved targets. Then a manipulated agent cannot send data to any address it likes.

Protect models and pipelines

Store model weights encrypted. Only a few roles with strong authentication may access the model registry and the training setup. Sign and check models before you deploy them, so only approved versions reach production.

Monitor all the time

Log prompts, tool calls, data access and denials, and analyse them in the SIEM. Odd patterns should trigger alerts. One example is an agent that suddenly pulls large amounts of data or contacts new targets.

Practical steps

  1. List all AI apps, agents and their technical accounts.
  2. Write down which data and tools each account can reach. Remove rights it does not need.
  3. Move RAG apps to rights checks per user.
  4. Put write actions and outside actions behind approvals or human confirmation.
  5. Classify model weights and training data and protect them to match.
  6. Turn on logging and define what you want to monitor.

Regulatory context

Access control, identity management and multi-factor authentication are baseline measures under NIS2 (Art. 21) and Germany's BSI Act. ISO/IEC 27001:2022 has matching controls for access control and privileged access rights. For high-risk AI, the EU AI Act requires robustness, cybersecurity and human oversight, among other things. Zero trust measures support these rules directly.

Conclusion

You cannot reliably secure language models against manipulation. So security has to come from the setup around them: tightly scoped identities, checked tool calls and full monitoring. SecTepe helps review AI rights concepts and runs penetration tests of AI apps.

Frequently asked questions

Do I need a separate zero trust architecture for AI?

No. AI parts fit into your existing identity and access management. They just get stricter rules for tool access and for data leaving the network.

Is a well-written system prompt enough protection?

No. People can get around the instructions in a system prompt. Limits that work are enforced outside the model.

More terms in “Zero Trust”

All terms in “Zero Trust” →