The expected purpose, tool sequence, and boundary conditions of an AI system before it begins operating. This is not a permission list. It is a behavioural reference point that helps security teams detect when a system has drifted from its approved task into unexpected or malicious activity.
Expanded Definition
An intent baseline describes what an AI system is expected to try to do, how it should sequence tools, and where its operating boundaries sit before execution begins. In NHI security, it is a behavioural reference point, not an access list, and it is used to spot drift, abuse, or prompt-injected behaviour that still appears technically valid. Definitions vary across vendors because some treat intent as a policy artifact while others treat it as a runtime model of expected actions.
That distinction matters because an agent can retain credentials yet still be out of bounds if it starts pursuing an unapproved objective, chains tools in an unexpected order, or expands scope beyond its intended task. The closest governance analogue is the control-and-monitoring logic described in the NIST Cybersecurity Framework 2.0, but intent baseline is more specific to agent behaviour than to general enterprise risk.
In practice, a sound intent baseline is built from approved workflows, tool call patterns, permitted data domains, and exception thresholds that can be monitored during execution. The most common misapplication is treating the baseline as a static permissions file, which occurs when teams define access but do not define expected behaviour sequence or success criteria.
Examples and Use Cases
Implementing intent baselines rigorously often introduces monitoring and tuning overhead, requiring organisations to weigh behavioural precision against operational flexibility.
- An internal support agent is allowed to open tickets, query knowledge bases, and draft responses, but not export customer records. A baseline flags the export attempt as intent drift even if the API key remains valid.
- A procurement agent can compare vendor quotes and generate summaries, yet it should not initiate payment workflows. If it starts calling finance tools, the sequence itself becomes a signal of deviation.
- An engineering assistant may create pull requests, but only after source review steps are satisfied. If it begins modifying secrets or deployment settings, the baseline reveals that its purpose has expanded beyond its mandate.
- In a monitored environment, teams can compare live tool use against expected patterns described in the Ultimate Guide to NHIs, then investigate anomalies alongside guidance in the NIST Cybersecurity Framework 2.0.
- A customer-service agent handling refunds may be allowed to issue one refund per case, but repeated refund tool calls against unrelated records indicate a behavioural shift that needs review.
Why It Matters in NHI Security
Intent baseline is critical because agentic systems can remain authenticated while becoming operationally unsafe. That makes traditional credential checks insufficient on their own. NHI security teams need intent baselines to detect when an agent is still “inside” its identity boundary but has crossed its behavioural boundary, especially in workflows involving secrets, privileged APIs, or delegated execution. The NHIMG research in the Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities, which makes behavioural drift a high-impact risk rather than a theoretical one.
For governance, the point is not to eliminate autonomy but to make autonomy inspectable. A defined baseline helps incident responders distinguish normal adaptation from suspicious escalation, and it supports post-event reconstruction when an AI system acts outside its expected role. It also complements broader identity controls discussed in the NIST Cybersecurity Framework 2.0 by giving analysts a way to ask whether the system behaved as intended, not just whether it had valid access.
Organisations typically encounter the need for an intent baseline only after an agent has sent the wrong data, invoked the wrong tool, or pursued the wrong objective, at which point the concept becomes operationally unavoidable to address.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, 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 | A2 | Agentic systems must be constrained to intended goals and tool use. |
| NIST CSF 2.0 | PR.PS-01 | Protective controls rely on expected system behavior and monitoring. |
| NIST AI RMF | GOV 1.2 | Governance requires defining and tracking intended AI use and boundaries. |
| NIST Zero Trust (SP 800-207) | SA-3 | Zero Trust validates each action, not just initial access. |
| OWASP Non-Human Identity Top 10 | NHI-08 | Behavioral drift in NHIs is a risk when service identities exceed their purpose. |
Define expected agent goals and block tool actions that fall outside approved intent.
Related resources from NHI Mgmt Group
- What is the difference between logging actions and logging intent for AI agents?
- What is the difference between role-based access and intent-based access for agents?
- What is the difference between RBAC and intent-aware access for autonomous workflows?
- What is the difference between access control and intent governance for AI agents?
