Teams should govern them by runtime behaviour, not by model family. Assistants need strong prompt and response controls, triggered workflows need untrusted-input screening and narrow tool scope, and autonomous agents need separate identities, scoped delegation, and traceability across each decision. A single AI policy rarely fits all three.
Why This Matters for Security Teams
Governance breaks down when AI is treated as one category instead of three distinct operating modes. A chat assistant that drafts text, a triggered workflow that calls tools after an event, and an autonomous agent that can plan, chain actions, and persist across tasks present different blast radii. The right question is not “which model is this?” but “what authority does it have at runtime, and who can prove it?” That is the same shift reflected in OWASP Agentic AI Top 10 and NIST AI Risk Management Framework.
Teams often over-control the assistant layer while under-governing the systems that can actually execute. That leaves prompt injection, tool abuse, and overbroad delegation as the real failure paths. NHIMG research on OWASP NHI Top 10 and incidents like CoPhish OAuth Token Theft via Copilot Studio show that the security boundary is usually the delegated identity, not the model itself. In practice, many security teams encounter compromise only after an assistant has already inherited tool access, not through intentional design.
How It Works in Practice
Governance should follow the operating mode. For assistants, control the conversation: redact or block sensitive inputs, constrain outputs, log prompts and responses, and apply policy to the content boundary. For triggered workflows, treat user or event input as untrusted, validate it before tool execution, and keep the tool scope narrow. For autonomous agents, move to explicit workload identity, short-lived delegation, and request-time authorization.
That means separate identities for separate purposes, not shared service accounts. Agents should authenticate as workloads, then receive just-in-time permissions for a single task or bounded mission. Ephemeral secrets and short TTL tokens reduce the time window for misuse, while traceability links each action back to the decision that allowed it. The strongest current guidance suggests pairing this with policy-as-code and runtime evaluation, so authorization can consider intent, context, and risk at the moment of action. Reference points include CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix.
NHIMG reporting on LLMjacking reinforces a practical lesson: once an agent can act on external tools, leaked credentials and stolen tokens become execution paths, not just account hygiene issues. These controls tend to break down when autonomous agents are allowed to reuse long-lived secrets across multiple tools because lateral movement becomes hard to distinguish from normal task completion.
Common Variations and Edge Cases
Tighter control often increases operational friction, requiring organisations to balance automation speed against review overhead and integration complexity. That tradeoff is real, especially when teams want agents to move quickly without blocking every action. Current guidance suggests the answer is not a single policy, but policy tiers based on capability and consequence.
Assistants embedded in knowledge work may only need content filtering, retrieval constraints, and human review before sensitive actions. Workflows that trigger on tickets, emails, or webhooks often need stronger input validation and approval gates before tool calls. Autonomous agents need the most restrictive pattern: isolated identities, least-privilege delegation, explicit task boundaries, and continuous auditability. There is no universal standard for this yet, but the direction of travel is clear in both the OWASP Top 10 for Agentic Applications 2026 and NIST Cybersecurity Framework 2.0.
Edge cases appear when one system plays all three roles. A helpdesk copilot may start as an assistant, trigger a workflow to update records, then call a more autonomous backend agent. In those environments, governance must follow the most privileged step in the chain, not the least risky front end. NHIMG’s Analysis of Claude Code Security and the Amazon Q AI Coding Agent Compromised case both illustrate why mixed-role systems need the stricter control set, not the friendliest one.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Covers prompt injection and tool abuse across assistants and agents. |
| CSA MAESTRO | TM-1 | Maps agentic threat modeling to delegation, tools, and autonomy risk. |
| NIST AI RMF | GOVERN | Supports accountability and risk ownership for autonomous AI behavior. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Relevant to secret handling and ephemeral credentials for agents. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero trust fits runtime authorization and least-privilege delegation. |
Classify each AI mode and apply runtime controls that match its tool and authority level.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
