Code-level checks can work for a small number of agents, but they become brittle as fleets grow. Teams get inconsistent enforcement, duplicated logic, and uneven auditability across workspaces. If one agent is updated and another is not, policy drift appears quickly. Central enforcement is usually more durable because the same rule applies everywhere by default.
Why This Matters for Security Teams
When safety checks live only inside individual agent code, they become part of the application rather than part of the control plane. That means every new agent, model swap, prompt path, or tool integration can create a new bypass surface. The risk is not just a missed validation step. It is inconsistent policy enforcement, weak auditability, and a false sense that the fleet is protected because one code path was reviewed. Guidance in the NIST AI Risk Management Framework points teams toward governable, repeatable controls rather than ad hoc checks embedded in one service.
This matters most for agentic systems because agents act, chain tools, and move data across workspaces with little human intervention. A safety check that is duplicated in several repositories rarely stays identical for long. One team tightens a rule, another forgets to update, and a third implements a local exception for testing that later becomes permanent. The result is policy drift that is hard to see from the outside and even harder to prove during an audit. In practice, many security teams encounter unsafe agent behaviour only after tool misuse or data exposure has already occurred, rather than through intentional policy validation.
How It Works in Practice
Code-level checks usually handle a narrow question such as whether an agent may call a tool, expose data, or continue a workflow. That can be useful, but it is not enough when the same organisation runs multiple agents with different owners, models, prompts, and release cadences. A stronger pattern is to centralise policy decisions so that the same rule applies across agents by default, then let each agent inherit those controls rather than reimplement them. This aligns with the direction of the OWASP Top 10 for Agentic Applications 2026, which treats agent behaviour as a security boundary, not just an engineering detail.
In practice, central enforcement often includes:
- policy checks before tool execution, not only inside business logic
- consistent approval rules for high-risk actions such as outbound email, file deletion, or credential use
- shared logging and decision records for audit and incident review
- versioned policy updates so all agents inherit the same baseline
- separate handling for test, staging, and production workspaces
Teams also need threat models for how an attacker could trigger unsafe behaviour through prompt injection, tool abuse, or model manipulation. The MITRE ATLAS adversarial AI threat matrix is useful for mapping those attack patterns, while CSA MAESTRO agentic AI threat modeling framework helps teams think about orchestration, trust boundaries, and agent-to-agent interactions. These controls tend to break down when every agent can ship its own safety logic independently because local exceptions accumulate faster than central review can catch them.
Common Variations and Edge Cases
Tighter central enforcement often increases deployment overhead, requiring organisations to balance speed of iteration against consistency and auditability. That tradeoff is real, especially when product teams want rapid experimentation or when different agents support different business risks. Current guidance suggests that not every check needs to be centralised at the same layer, but there is no universal standard for this yet. Low-risk validation can remain local if it is duplicated safely, while high-impact controls should be enforced where they cannot be bypassed by a single code change.
Edge cases usually appear when agents span multiple environments or rely on shared tools owned by separate teams. A local code check may look strong in one workspace but fail when the same agent is called through another interface, another prompt template, or another deployment pipeline. That is why practitioners should pair application-level checks with control objectives that map to security governance, logging, and least privilege in frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls. For teams building toward durable AI governance, the important question is not whether a check exists in code, but whether the policy survives model updates, repository forks, and operational exceptions.
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 ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Local checks often fail against agent-specific abuse paths and unsafe tool use. |
| NIST AI RMF | GOVERN | This question is fundamentally about repeatable AI governance and accountability. |
| MITRE ATLAS | AML.TA0002 | Agent safety gaps are often exploited through adversarial input and manipulation. |
| NIST CSF 2.0 | PR.DS | Central policy enforcement supports consistent protection of data and system behaviour. |
| NIST AI 600-1 | GenAI systems need consistent runtime safeguards, not only per-service code checks. |
Implement baseline controls that protect agent workflows and sensitive data across environments.
Related resources from NHI Mgmt Group
- What breaks when an AI agent can act inside a pipeline without human approval?
- What breaks when an AI agent can still write to production during a code freeze?
- What breaks when an AI agent moves from bug analysis to code modification?
- What breaks when AI traffic is governed only inside application code?
