> For the complete documentation index, see [llms.txt](https://docs.solcis.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solcis.ai/references/concepts/ai-agent-governance.md).
# AI agent governance
AI agent governance spans policy, oversight, and enforcement. Most governance tooling is strongest in the first two. This explains the runtime enforcement layer and where it fits.
AI agent governance spans three layers – policy, oversight, and enforcement – and most governance tooling is strongest in the first two. This page explains what the runtime enforcement layer does, why autonomous agents need it, and how it fits alongside the governance program you already run. For the enforcement layer itself, the full model is [runtime AI compliance](/references/concepts/runtime-ai-compliance.md).
AI agents are not applications you review once at intake and revisit each quarter. They chain tool calls, read data, and reach external APIs at machine speed, often in sequences no reviewer inspected in advance. Controls built around human review break down when AI agents move from generating outputs to taking actions autonomously. That is why three ideas that are often used interchangeably need to be kept apart:
* **AI governance** is the program. It sets the policies, risk assessments, and oversight for how AI is used.
* **Agentic compliance** is the proof. It is what you can demonstrate, action by action, about how an agent behaved against the controls you adopted.
* **Runtime enforcement** is the control point. It binds an individual action at the moment it happens.
## Key takeaways
* AI agent governance has three layers: policy and documentation, risk assessment and oversight, and runtime enforcement.
* Governance tooling is strongest in the first two layers. Enforcing your own adopted controls on each agent action, traced to the framework clause, is where most programs are thin.
* Governance platforms typically enforce at workflow gates or apply platform-defined policies. Runtime enforcement applies your adopted controls to each tool call, data read, and external API call in the action path.
* A compliance claim about an agent holds up when four conditions are met: adopted controls, control-to-clause traceability, per-action evidence, and independent verifiability.
* The runtime enforcement layer sits downstream of your governance platform, not in place of it.
## What is AI agent governance?
AI agent governance is the discipline of setting policy, assessing risk, overseeing use, and enforcing controls on autonomous AI systems that plan, decide, and act on their own. It spans the full lifecycle, covering intake and approval of a new agent, operation and monitoring, and retirement.
Governance is not a single tool. It is a program that has to hand off cleanly between layers. Policy and documentation sit at the top. Risk assessment and human oversight sit in the middle. Runtime enforcement of the controls you have adopted sits at the bottom, on the path of each agent action. Most programs cover the first two layers well. The third is where most are thin.
## What are the layers of AI agent governance?
AI agent governance has three layers that run in sequence and hand off to each other. The first two describe and record. Only the third binds an agent's next action.
### Policy and documentation
This is where the program is defined. It includes the AI and agent inventory, model cards, adopted frameworks such as ISO/IEC 42001 and the NIST AI Risk Management Framework, acceptable-use policies, control libraries, and the traceability that maps each internal control back to a specific framework clause. This layer produces the artefacts an auditor asks for first.
### Risk assessment and oversight
This is where new AI use cases are triaged, tiered, and approved. It covers intake workflows, impact assessments, risk scoring, reviewer sign-off, and the periodic re-review of agents already in production. Human judgement lives here: a risk officer deciding whether an agent given access to customer payment data and the ability to send external emails should be tiered high-risk and routed for additional sign-off before it goes live, and the same judgement at each checkpoint after that.
### Runtime enforcement
This is the control point that acts on each agent action as it happens. It intercepts a tool call, checks whether the action falls within the boundary defined by the adopted controls, and produces a tamper-evident record of the decision and the evidence supporting it. Where the first two layers describe intended behaviour, this layer binds actual behaviour. This is the layer [runtime AI compliance](/references/concepts/runtime-ai-compliance.md) describes in full.
## How is AI agent governance different from runtime enforcement?
Governance platforms and runtime enforcement layers do different work in different parts of the stack. A governance platform is a system of record for policy, risk, and oversight. A runtime enforcement layer is a control point on the execution path.
In June 2026, Gartner published its first [Magic Quadrant for AI Governance Platforms](https://www.gartner.com/en/documents/8006369), evaluating 13 vendors. Gartner describes these platforms as centrally defining, approving, and enforcing responsible AI policies across AI use cases, applications, and agents, and some include runtime capabilities. The distinction this page draws is narrower: whether the controls enforced on each agent action are the organisation's own adopted controls, traced to the framework clause they satisfy, with per-action evidence reported back to the system of record. In our view, that is where most programs remain thin, whichever platform they use.
The table below sets out the split.
| Dimension | Governance platform | Runtime enforcement layer |
| ----------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| Primary artefact | Policies, AI/agent inventory, risk register, control library | Per-action decisions on individual agent actions |
| When it acts | Design-time and at workflow gates | Execution-time, on each action in the enforcement path |
| Enforcement point | Approve, block, or re-tier at intake and review steps; some also apply platform-defined policies | Intercept a tool call, data read, or external API call as it happens |
| Scope of decision | About an agent, model, or use case as a whole | About one specific action an agent is about to take |
| Evidence produced | Approval records, control-to-clause mappings, periodic audit logs | Tamper-evident action log with the decision, inputs, and adopted control applied |
| Human involvement | Reviewers, approvers, risk owners in the loop | Runs automatically per action; escalates to a person where a control requires it |
| Where it sits | System of record, upstream | Control point, downstream, reports evidence back up |
| Category example | GRC platforms and AI governance platforms | Solcis Policy Engine and adjacent runtime control layers |
Why the seam matters is easier to see with a specific data point. Gartner predicted in June 2025 that over [40% of agentic AI projects](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) will be cancelled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. The last of these is where the seam between layers matters. Assessing risk and deciding which controls apply is the job of the oversight layer, and most programs do it. What they often lack is the layer that makes those controls hold on each action once the agent is running.
The governance platform defines which controls the organisation has adopted and how each maps back to a framework clause. The runtime enforcement layer consumes those adopted controls and applies them on the action path, then sends per-action evidence back upstream so it can be aggregated into the audit trail. Neither can substitute for the other.
## What does agentic compliance actually require?
Agentic compliance means proving that an agent behaved the way your controls require, checked action by action rather than reviewed once a quarter. A policy in a wiki, a signed acceptable-use form, or a ticked box on a risk register all feed into compliance. On their own, they are not compliance.
Four conditions have to hold for a compliance claim about an agent to stand up to scrutiny:
* **Adopted controls.** The controls being enforced are the specific ones your organisation chose and signed off on, not a vendor's generic guardrails shipped in the box.
* **Control-to-clause traceability.** Each adopted control is mapped back to a specific clause in a named framework, so an auditor can trace an action from the decision to ISO/IEC 42001, NIST AI RMF, ISO/IEC 23894, the EU AI Act, or any national AI framework or regulation.
* **Per-action evidence.** Every enforced action produces a tamper-evident record of what the agent did, what data it touched, which control was applied, and what the decision was.
* **Independent verifiability.** A third party can re-examine the decision from the evidence alone and reach the same result without trusting the vendor's word for it.
These are the conditions the [properties of runtime AI compliance](/references/concepts/runtime-ai-compliance.md) are designed to meet. A signed policy, a quarterly review, and a completed model card are all useful, but none of them binds what an agent does at machine speed, and none of them, on their own, produces evidence a regulator or auditor can independently verify. That is the work of the runtime enforcement layer.
## Why do agents need runtime enforcement, not just governance?
Governance without enforcement produces documents, compliance without enforcement produces assertions, and only enforcement turns either of them into evidence tied to a specific action.
The longer answer is a problem of speed and consequence. Agents chain tool calls at API speed. They can complete a sequence of actions, some of them irreversible, before any human reviewer sees the first one. The traditional GRC assumption of periodic sampling and after-the-fact review does not hold at that tempo. Five risk classes are specific to autonomous agents:
* **Irreversible actions.** An agent that can send a payment, publish to a customer channel, or call a destructive API needs control on the action path, not on the quarterly review.
* **Cascading failures across multi-agent chains.** When one agent's output becomes another's input, a single out-of-scope action can propagate through the chain before it is caught.
* **Goal drift.** Agents optimising towards a stated goal can, over long sessions or after tool updates, move outside their intended scope.
* **Adversarial inputs.** Prompt injection and related attacks can hijack an agent's goal, turning a legitimate request into an instruction to exfiltrate data or invoke tools that were never sanctioned.
* **Identity and privilege misuse.** Agents that run on a user's delegated credentials or a shared service account can reach systems and data beyond what their task requires, and their actions are hard to attribute.
These map closely to risks catalogued in the [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/), and prompt injection remains the leading risk in the [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/). The [agentic compliance](/references/concepts/agentic-compliance.md) page covers why agents make each of them harder to control.
Documentation cannot intercept any of these. Policies describe intended behaviour, model cards describe capability, and risk registers describe what was assessed at intake. All are essential parts of a governance program, and none stop an out-of-scope tool call at the moment it happens. That is what the runtime enforcement layer is for, and why it sits downstream of the documentation rather than in place of it.
## How does enforcement fit alongside your governance program?
Runtime enforcement is downstream of the governance platform, not a substitute for it. Whichever platform an organisation selects to manage its governance program, that platform remains the system of record for policy and approvals. Enforcement runs on the action path underneath it, applies the controls that platform defines, and reports evidence back up into it.
In practice, the governance platform keeps doing intake, risk scoring, and approvals as before. What changes is that its policy decisions now reach down to the individual action, instead of stopping at the workflow gate. Enforcement doesn't own the control library, doesn't set risk tiers, and doesn't approve use cases. Governance doesn't intercept tool calls or produce per-action evidence. Each stays in its lane.
Solcis provides this layer in two parts. Solcis Compliance Studio takes the controls your governance platform has defined and sends enforcement policies down to the Solcis Policy Engine, which enforces them on each agent action. Compliance Studio then reports the evidence back up, through its GRC integrations, into the platform you already treat as your system of record. See [runtime AI compliance](/references/concepts/runtime-ai-compliance.md) for the full model.
## Frequently asked questions
What is the difference between AI governance and AI agent governance?
AI governance covers all AI systems, from predictive models to generative applications. AI agent governance is the subset that deals with autonomous systems that plan, decide, and act on their own. Agents introduce risks that non-agentic AI does not: irreversible actions, tool-call chaining, multi-agent orchestration, and machine-speed decisions. That is why agents require a runtime enforcement layer that traditional AI governance programs did not need to specify.
Is AI agent governance the same as agentic compliance?
No. Governance is the program covering policy, risk assessment, oversight, and enforcement across an agent's lifecycle. [Agentic compliance](/references/concepts/agentic-compliance.md) is runtime AI compliance applied to autonomous agents: what you can prove about each agent action against the controls your organisation has adopted, traced to the framework clause, with independently verifiable evidence. Governance defines the controls; agentic compliance shows they held in practice. You can have a governance program on paper without compliance evidence to back it up, which is the gap runtime enforcement closes.
Do I need both an AI governance platform and a runtime enforcement layer?
Yes, for autonomous agents in regulated environments. A governance platform is the right tool for policy, intake, risk assessment, oversight, and control-library management. A runtime enforcement layer consumes the controls the governance platform defines, applies them on each action at machine speed, and sends per-action evidence back upstream. The two are complementary. The Solcis Policy Engine is an example of the enforcement layer, with Solcis Compliance Studio connecting it to whatever governance platform you already use.
What does runtime enforcement actually intercept?
It sits on the action path of each agent and intercepts the concrete things an agent does: tool calls, data reads and writes, external API calls, actions against downstream systems, and outputs sent to users or other agents. For each action, it checks the action against the adopted controls, produces a decision, and records tamper-evident evidence of what happened, what data was involved, and which control applied.
Which frameworks cover AI agent governance?
No single framework covers AI agent governance end to end. The most relevant are:
* **Singapore IMDA's** [**Model AI Governance Framework for Agentic AI**](https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai), first published in January 2026 and one of the first governance frameworks written specifically for agentic AI.
* **The** [**OWASP Top 10 for Agentic Applications**](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/), which catalogues security risks specific to autonomous agents.
* **ISO/IEC 42001** (AI management systems), **ISO/IEC 42005** (AI system impact assessment), and **ISO/IEC 23894** (AI risk management), which apply to agents as AI systems but are not agent-specific.
* **The NIST AI Risk Management Framework** and its Generative AI Profile.
The EU AI Act sets legal obligations for high-risk AI systems, which can include some agent deployments. Sector-specific regulation also applies where agents touch financial services, government, or critical infrastructure. See the [AI regulatory landscape](/references/ai-regulatory-landscape.md) for jurisdiction-specific requirements.
## Related
* [Runtime AI compliance](/references/concepts/runtime-ai-compliance.md) – the full model for the enforcement layer.
* [Agentic compliance](/references/concepts/agentic-compliance.md) – what changes when the actor is an autonomous agent.
* [AI regulatory landscape](/references/ai-regulatory-landscape.md) – how obligations differ by jurisdiction.
* [Glossary](/references/glossary.md) – definitions for terms used across Solcis documentation.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.solcis.ai/references/concepts/ai-agent-governance.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.