AI assistants often need broad, dynamic access to data and tools, which can conflict with zero trust principles if access is not continuously verified. To stay aligned with zero trust, organisations need strong authentication, policy checks at runtime, and step-up controls before an assistant can perform sensitive actions.
Why Zero Trust Gets Harder When Assistants Can Act, Not Just Answer
AI assistants become difficult to secure under zero trust because they are not passive systems. They may call APIs, retrieve records, trigger workflows, and chain tools based on live prompts or delegated goals. That means access is no longer a fixed role problem. It becomes a runtime authorisation problem, which is exactly where zero trust can become brittle if the organisation still relies on static entitlements and broad service accounts. NIST SP 800-207 Zero Trust Architecture makes the point that trust must be continuously evaluated, not assumed after login. For AI assistants, that evaluation has to cover the identity of the workload, the request context, and the specific action being attempted.
NHIMG research on secrets exposure shows why this matters operationally: The State of Secrets in AppSec found the average time to remediate a leaked secret is 27 days, while LLMjacking documents how quickly exposed AI and cloud credentials are abused. Once an assistant can reach sensitive systems, a single over-permissioned token can defeat an otherwise sound zero trust design. In practice, many security teams discover this only after an assistant has already been given more reach than any human operator would ever receive intentionally.
How to Apply Zero Trust to AI Assistants Without Freezing the Business
The practical answer is not to block assistants from doing work. It is to replace standing access with workload identity models such as SPIFFE and SPIRE, then issue JIT credentials only for the task in front of the assistant. That gives the system a cryptographic identity for what it is, while limiting what it can do to what it has been explicitly allowed to do at that moment. Current guidance suggests using policy-as-code so runtime checks can evaluate the prompt, the target system, the data classification, and the action sensitivity before the assistant proceeds.
This is where zero trust becomes real for autonomous workflows:
- Use NIST SP 800-207 Zero Trust Architecture to anchor continuous verification and deny-by-default access decisions.
- Issue short-lived tokens and ephemeral secrets for each task instead of long-lived shared credentials.
- Separate read, write, and act permissions so an assistant that can summarise data cannot also modify it.
- Require step-up approval or human-in-the-loop checks for high-impact actions such as payments, deletions, or privilege grants.
For agentic systems, this should be combined with NHIMG standards guidance so NHI governance, PAM, RBAC, and ZSP are aligned around the same workload. Best practice is evolving, but the direction is clear: authorise the intent of the action, not just the token attached to the assistant. These controls tend to break down when multiple tools share the same service account because one compromised path can silently inherit every other permission attached to that identity.
Where the Model Breaks Down in Real Environments
Tighter runtime controls often increase latency and operational overhead, so organisations must balance security precision against user experience and automation throughput. That tradeoff becomes sharper in multi-agent chains, where one assistant delegates to another and the access decision must be re-evaluated at each hop. There is no universal standard for this yet, especially for how to represent intent-based authorisation across vendors and orchestration layers.
This is also why AI-specific governance matters. The DeepSeek breach illustrates how quickly sensitive information can spread once data, credentials, and model workflows are not cleanly separated. For some environments, especially legacy estates with static IAM, the realistic first step is not full autonomous enablement but segmentation, JIT elevation, and narrow tool scopes. That is the practical path to zero trust for assistants: reduce standing privilege, enforce real-time policy checks, and treat every tool call as a fresh decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Addresses excessive tool access and unsafe agent actions under autonomous workflows. |
| CSA MAESTRO | Directly covers agentic AI controls, identity, and policy enforcement for assistants. | |
| NIST AI RMF | GOVERN | Governance is needed for accountability over autonomous assistant behaviour. |
Assign ownership, review AI risk, and document approval paths for assistant-driven actions.
