Observable condition
An AI-enabled agent can create a record, send a message, update a workflow, call an external service or trigger another system. The business can describe what the agent is meant to do, but it cannot easily answer which permissions it used, why a particular action happened, what exception path was taken or who would notice an unexpected outcome.
Realisation
Once a system can act, governance has to cover more than the quality of generated text. The operating question becomes whether the organisation can map, measure and manage the system’s behaviour across its lifecycle. NIST’s AI Risk Management Framework is explicitly intended to help organisations incorporate risk management into the design, development, use and evaluation of AI systems, and NIST continues to maintain implementation resources while AI RMF 1.0 is being revised.
Identification
This is an agentic-AI operational-governance and observability problem.
Diagnosis
The mechanism appears when action capability is added faster than operational control. Permissions may be inherited from a powerful service account, logs may describe technical calls without the business reason, approval boundaries may be implicit, and exception handling may depend on the model deciding when to stop. The organisation can then have automation authority without equivalent accountability visibility.
Commercial impact
The value wrapper is governance, risk, resilience and automation readiness. Weak visibility makes it harder to distinguish intended automation from an abnormal action, investigate incidents, prove which controls operated or improve the workflow after exceptions. The issue can also slow useful AI adoption because teams cannot confidently expand the action surface.
Common misidentification
The problem is sometimes reduced to whether the model is accurate. Accuracy matters, but an action-capable system can still require governance even when its individual outputs look reasonable. Permissions, traceability, stop conditions, human escalation and outcome monitoring are operating-design concerns.
Possibility
A stronger model treats each agent as an operational actor with a defined purpose, bounded permissions, observable actions, accountable owner and explicit escalation rules. Business events and outcomes can be logged alongside technical calls so governance can see not only that an API was used but what operating decision it represented.
Intervention
Inventory each action an agent can take. For every action, record the system touched, permission used, business purpose, maximum consequence, required evidence, stop condition, exception path and accountable owner. Then test whether the organisation can reconstruct a representative transaction from trigger through action to outcome. Reduce permissions or add approval boundaries where the evidence is weaker than the authority granted.
Practical diagnostic questions
- Which business actions can each agent initiate without a person?
- Are its permissions narrower than the account or system it uses?
- Can an accountable owner reconstruct why an action occurred?
- What causes the agent to stop and escalate?
- Are abnormal actions and business outcomes monitored, not only technical errors?
Bottom line
If an AI agent can act faster than the organisation can observe and govern those actions, the control model is behind the automation model.