Use the repository for prevention and runtime for detection. Policy linting, secret scanning, trust validation, and CI/CD gates should stop bad configurations before deployment, while runtime telemetry should confirm whether an approved policy behaves as intended. That division of labour reduces both false confidence and avoidable exposure.
Govern the repository as the prevention layer
The repository layer should be the place where policy is made machine-checkable before an agent ever reaches production. For autonomous agents, that means treating prompts, manifests, permissions, tool declarations, and secret handling as reviewable configuration, not informal implementation detail.
Pre-deployment controls work best when they fail closed. Policy linting, secret scanning, and trust validation can block unsafe agent definitions early, while CI/CD gates stop drift from becoming an approved runtime pattern. That is the right layer for standards that should hold before the agent is allowed to act.
When repository governance is done well, the approval event becomes meaningful: it means the agent has passed a defined prevention threshold, not merely that someone has documented its existence. That distinction matters because autonomous systems often look compliant in documentation while still carrying unsafe defaults, overbroad tool access, or embedded secrets.
Use runtime controls to verify actual behaviour
Runtime governance answers a different question: not whether the agent was approved, but whether it behaves inside the guardrails that were approved. Telemetry, action logs, policy decision traces, and anomaly signals are the evidence source for that layer, because they show what the agent actually did under live conditions.
This is especially important when an agent’s context, tool chain, or downstream systems change after deployment. A policy that looked sound in review can still produce unsafe outcomes if the agent begins chaining actions differently, receives unexpected inputs, or encounters a tool response that shifts its behaviour.
AI Agent Observability, Audit and Incident Response Guide is useful here because runtime governance only works when teams can attribute actions, detect deviation, and revoke access quickly enough to matter. Zero Trust for AI Agents reinforces the same operational idea: verify each request and remove standing trust, rather than assuming the repository approval permanently covers every future action.
Why the split matters for agent governance
Repository and runtime controls solve different failure modes. The repository prevents known-bad configurations from shipping, while runtime detects approved configurations that become unsafe in context, scale, or execution path. If teams collapse those layers, they usually get either too much blocking up front or too little visibility after release.
Agentic AI Security Policy Template maps well to this split because it frames registration, oversight, tools, monitoring, and retirement as separate governance obligations. AI Agent Authorisation Guide adds the access-control side of the picture: the policy should limit what the agent may do, but runtime checks must still confirm each sensitive action is justified at the moment it occurs.
For teams governing many agents, the practical issue is scale. Repository controls give you repeatable preventive discipline, but runtime telemetry is what reveals whether the aggregate population is drifting into excessive agency, noisy exceptions, or unreviewed behaviours that were never obvious in code review.
Risk and Threat Considerations
Autonomous agents create a control gap when approval and execution are treated as the same event. A clean repository review can still leave you exposed if the runtime environment changes, if a tool response is manipulated, or if the agent’s effective authority expands beyond the approved design.
Failure mechanism: Unsafe configurations pass the repository gates, then the live agent accumulates risk through unexpected inputs, overbroad tool access, stale assumptions, or behaviour that diverges from the reviewed policy.
Impact: Teams can end up with false confidence, delayed detection, and avoidable exposure across secrets, actions, and connected systems, especially when runtime logs are too thin to explain what the agent actually did.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent governance must limit privilege before and during execution. |
| ASI08 — Cascading Failures | Runtime drift in one agent can propagate to connected systems and agents. | |
| Recommendation — Enforce least privilege and per-action authorization for autonomous agents. Add runtime containment and blast-radius checks for agent failures. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime telemetry is needed to detect when approved agent behaviour diverges. |
| CM-3 — Configuration Change Control | Repository governance depends on controlled approval of agent configuration changes. | |
| AC-6 — Least Privilege | Autonomous agents should only receive the authority needed for approved tasks. | |
| Recommendation — Monitor agent actions and alert on anomalous execution patterns. Gate agent configuration changes through formal review and approval. Restrict agent privileges to the minimum required for each task. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Agent access must be governed before deployment and validated at runtime. |
| DE.CM-01 — Monitoring for Anomalous Activity | Runtime monitoring is essential to confirm policy behaves as intended. | |
| Recommendation — Apply access control that matches each agent’s approved role and action scope. Detect unexpected agent behaviour with continuous monitoring. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Repository-layer controls depend on secure configuration baselines and change control. |
| A.8.16 — Monitoring activities | Runtime governance requires logs and telemetry that reveal actual agent behaviour. | |
| Recommendation — Maintain controlled baselines for agent configurations and policy files. Collect and review telemetry to validate agent actions against policy. | ||
| ISO/IEC 42001:2023 | 8.2 — AI risk treatment | Autonomous agents require both preventive and runtime risk treatment decisions. |
| Recommendation — Treat agent risks with controls that span deployment approval and live oversight. | ||
Practitioner Guidance
What to verify: Require evidence that every approved agent has both a pre-deployment policy check and a live telemetry path, and that the two are linked by an auditable identifier. If you cannot trace an observed action back to the policy version that authorised it, the control design is incomplete.
Decision rule: If a control can be enforced before deployment, enforce it in the repository; if it depends on context, runtime state, or actual behaviour, enforce it at runtime. Do not rely on one layer to compensate for a missing control in the other.
Practitioner takeaway: The strongest governance model is not “more review,” it is clear separation of preventive approval and behavioural verification, with a fast path from runtime deviation to containment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org