Use the decision test, not the vendor label. If the system only retrieves knowledge or drafts responses, keep it in the assistant category. If it can independently choose a tool, execute a change, or trigger remediation, it crosses into governed agent behaviour and needs identity controls to match.
Why This Matters for Security Teams
The assistant versus agent distinction is not a naming exercise. It determines whether the system is merely generating output or whether it is making runtime decisions that can change data, trigger workflows, or move laterally across tools. Once a service can choose actions on its own, static RBAC assumptions become fragile because access no longer follows a fixed human pattern.
That is why current guidance increasingly treats goal-driven autonomy as the security boundary. If a system can decide when to act, then identity, authorisation, logging, and revocation must be designed for machine speed rather than human review cycles. NHI Management Group research on OWASP NHI Top 10 and the OWASP Agentic AI Top 10 both reflect this shift toward runtime control, not just pre-approved access lists. In practice, many security teams encounter agent-like behaviour only after a workflow has already executed an unintended change, rather than through intentional design review.
How It Works in Practice
Security teams should classify the system by what it can do, not by what the vendor calls it. A true assistant can retrieve, summarise, draft, or recommend. An agent can independently decide to call a tool, submit a ticket, modify records, run remediation, or chain actions across systems. That difference changes the governance model.
For assistants, access can often stay bounded to read-only retrieval and controlled content generation. For agents, best practice is evolving toward runtime authorisation, short-lived credentials, and workload identity. The practical pattern is to issue the minimum capability required for a specific task, then revoke it immediately after completion. That means using ephemeral secrets, task-scoped tokens, and policy evaluation at request time rather than relying on broad standing permissions. Standards such as the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework both point toward risk-based controls that match autonomy level.
A practical decision flow looks like this:
- If the system only retrieves or drafts, keep it as an assistant and limit it to read or suggestion paths.
- If it can choose a tool or execute a side effect, require agent governance, including explicit approval boundaries.
- If it can chain actions, add workload identity, per-task credential issuance, and detailed audit trails.
- If it can remediate or modify production systems, treat it like a privileged workload with time-boxed authorisation.
This model aligns with real-world incidents such as the AI LLM hijack breach, where exposed credentials and tool access became operational attack paths. These controls tend to break down when an assistant is quietly upgraded to tool use in production because the surrounding IAM and approval model was never redesigned.
Common Variations and Edge Cases
Tighter autonomy controls often increase workflow friction, requiring organisations to balance speed against the risk of unintended execution. That tradeoff matters because not every tool-using system is a full agent, and not every agent should have production authority. Current guidance suggests using a graduated model rather than a binary label.
One common edge case is the copilot that occasionally invokes a tool through user approval. If the user remains the final decision-maker, the system can often stay in assistant territory, but only if the tool action is truly contingent on a human confirmation step. Another edge case is an internal remediation bot that only acts inside a narrow playbook. Even then, if the bot can independently select which playbook to run, it is already acting as an agent and should be governed accordingly.
There is no universal standard for this yet, so organisations should document a local threshold based on autonomy, side effects, and blast radius. NHIMG reporting on the State of Secrets in AppSec is a useful reminder that secret exposure and long-lived credentials multiply risk once a system can act on its own. The safest default is to keep anything with independent execution authority on a short leash unless the business case clearly justifies agent controls.
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 | A2 | Focuses on agent autonomy and tool misuse, central to assistant vs agent decisions. |
| CSA MAESTRO | 0 | MAESTRO models risk around autonomous workflows and agentic control boundaries. |
| NIST AI RMF | GOVERN | AI RMF GOVERN addresses accountability when AI can independently act. |
Classify systems by autonomous action capability and require runtime controls before tool access expands.
