They should begin with observation-only controls, capture action-level telemetry, and build a baseline of normal behaviour before enforcing deny rules. That sequence reduces false positives and prevents policy from being written against assumptions instead of evidence. Once the baseline is stable, teams can harden policy around observed workflows rather than generic templates.
Why Observation-First Governance Matters
AI agents change the security problem from static policy enforcement to runtime decision-making. If teams block actions too early, they often block legitimate workflows they have not yet understood, or they create brittle rules that fail the first time the agent changes tools, prompts, or task ordering. Observation-first governance gives security teams a way to understand what the agent actually does, which actions are routine, and where the real trust boundary sits before they decide what should be denied.
The practical value is simple: policy should be written against observed behaviour, not assumed intent. That matters most when agents can read data, invoke tools, or chain actions across systems, because the harmful outcome is often not a single forbidden call but a sequence that looks normal until the final step. Current guidance suggests that governance should be built around action-level telemetry, approval states, and escalation points, not just high-level “agent on or off” controls. The AI Agents: The New Attack Surface report is a useful reminder that many organisations still lack reliable visibility into what their agents access and do. In practice, teams usually discover the real control gap only after an agent has already exercised more privilege than the policy assumed.
How It Works in Practice
Observation-only controls should capture the full action chain, not just prompts and outputs. That means logging tool calls, target systems, data categories accessed, time of execution, human approvals, retries, and any failed or overridden actions. The goal is to build a baseline of what “normal” means for each agent, each task class, and each operating context.
- Start with read-only visibility on the highest-value workflows first.
- Classify actions by sensitivity, for example data read, data write, external call, permission change, or destructive operation.
- Separate routine automation from exceptional behaviour, because exceptions are where policy usually needs the most care.
- Compare agent activity against the business process it is supporting, not against generic automation templates.
Once teams have enough evidence, they can move from observation to selective enforcement. Blocking rules should target high-risk action classes, unsafe destinations, or unapproved escalation paths, rather than broad behaviour patterns that may be legitimate in some contexts. This is especially important where agent outputs depend on changing prompts, models, or tool availability, because a deny rule that looks safe in testing may break a production workflow when the agent adapts to a new input or exception path. The OWASP Top 10 for Agentic Applications 2026 is a strong fit for structuring those observed failure modes into concrete control priorities. These controls tend to break down when teams try to enforce them before they have enough telemetry on cross-system tool use and exception handling.
Common Variations and Edge Cases
Tighter governance often increases operational friction, so teams have to balance safety against the speed and flexibility that make agents useful in the first place. The right sequence is not always “observe everything, block later” in a rigid sense, because some actions are too sensitive to permit during learning, especially destructive writes, credential exposure, or external exfiltration paths.
In higher-risk environments, a mixed model works better: observe low-risk actions broadly, but pre-block a small set of clearly dangerous operations from day one. That approach reduces blast radius while still preserving the evidence needed to understand normal behaviour. Another edge case is shared agent infrastructure, where one policy set covers many use cases. In those environments, generic rules are usually too blunt, because the same action can be acceptable for one workflow and dangerous for another. The better pattern is to govern by agent, task, and data class together, then tighten only after the baseline is stable. The NIST AI Risk Management Framework helps teams keep that balance between risk reduction and operational usefulness. Best practice is evolving here, but the clearest rule is that enforcement should follow evidence, not assumption.
Risk and Threat Considerations
The material risk is that agents can take actions beyond their intended scope before anyone understands their real behaviour. That creates exposure across data access, downstream system changes, and governance accountability, especially when teams cannot audit which actions occurred or why they were permitted.
Failure mechanism: The control fails when policy is enforced against a guessed workflow instead of an observed one. In that state, teams either over-block and break legitimate operations, or under-block and allow an agent to use valid permissions in unsafe combinations, including access to sensitive data, external tools, or irreversible actions.
Impact: The result can be false positives, broken automation, hidden overreach, weak incident reconstruction, and in the worst case, unauthorised data handling or destructive system activity that was never properly constrained.
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 MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A6 — Excessive Agency | Governance must limit agent actions after observing real workflows. |
| A2 — Insecure Output Handling | Observed action-level telemetry helps detect unsafe downstream agent behaviour. | |
| Recommendation — Constrain agent actions to observed, justified workflows before expanding deny rules. Log and review agent actions that can alter data, systems, or trust boundaries. | ||
| NIST AI RMF | GOVERN — Govern and manage AI risk | Observation-first policy supports accountable AI risk governance. |
| MAP — Map AI risks and contexts | Baseline building requires understanding agent context, uses, and limits. | |
| MEASURE — Measure AI system behaviour and risk | Action telemetry and baselining are measurement activities for agent behaviour. | |
| Recommendation — Establish AI risk governance that uses evidence before enforcing control decisions. Map each agent's context, intended use, and likely failure modes before policy enforcement. Measure agent actions and exceptions so policy can be based on evidence. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Governing agents needs a risk strategy for phased observation and enforcement. |
| DE.CM-01 — Security Continuous Monitoring | Action-level telemetry is continuous monitoring for agent behaviour. | |
| PR.AA-01 — Identity and Access Management | Agent actions depend on access boundaries that must be governed to observed scope. | |
| Recommendation — Define a phased AI agent risk strategy that starts with observation and matures into enforcement. Monitor agent actions continuously so deviations can be baselined and detected. Limit agent access to the minimum observed workflow scope. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | AI agents often execute tool-like actions that resemble scripted commands. |
| T1078 — Valid Accounts | Agents commonly act through legitimate accounts, making misuse harder to spot. | |
| Recommendation — Hunt for scripted or tool-driven agent actions that cross approved boundaries. Monitor legitimate accounts used by agents for abnormal action chains and scope creep. | ||
Practitioner Guidance
What to prioritise: Instrument the agent before you harden it. If action-level telemetry is incomplete, you do not yet know which denials are safe, which approvals matter, or where the actual blast radius begins.
Decision rule: If an action can change state, expose sensitive data, or trigger another system, treat it as evidence-gathering territory first unless it is clearly high impact and pre-blocked by design.
What good looks like: Security and platform teams can explain, from logs alone, what the agent attempted, what it succeeded at, what was approved, and which actions should become deny rules without disrupting valid work.
Practitioner takeaway: The safest agent policy is not the strictest one, it is the one that is grounded in observed behaviour and can be tightened without guessing at how the agent really operates.
Related resources from NHI Mgmt Group
- How should security teams govern AI agents that use OAuth access?
- How should security teams govern AI agents that can access enterprise systems?
- How should security teams govern semiautonomous AI agents before they go live?
- How should security teams govern machine identity credentials in agentic AI environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
