> 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/agentic-compliance.md).

# Agentic compliance

Agentic compliance is the agent-specific case of runtime AI compliance: enforcing your adopted controls on what an autonomous agent does, at the moment it acts.

Agentic compliance is runtime AI compliance applied to autonomous agents: enforcing your adopted controls on the actions an agent takes, at the moment it acts, traced to the framework clause, with tamper-evident and independently verifiable evidence. It is a focused case of the broader discipline, not a separate one.

Start with [runtime AI compliance](/references/concepts/runtime-ai-compliance.md) for the definition, the properties, and how it differs from AI governance, guardrails and observability. This page covers only what changes when the actor is an autonomous agent.

## Key takeaways

* Agents choose their own actions, chain them at machine speed, and read content that can redirect them. The moment of action is the one point where a control reliably applies.
* An agent acts on someone else's authority. Each action needs to be attributable to the agent and traceable to the person or process it acts for.
* In multi-agent chains, attribution has to hold across every hop.
* The properties of runtime AI compliance do not change for agents; they matter more.

## Why agents are the hardest case

Runtime AI compliance governs what any AI system does – AI-powered software, agents, or models. Agents are where the problem is hardest, for five reasons.

* **They choose their own actions.** An agent plans towards a goal rather than following a fixed script. No one specifies its tool calls in advance, and the same request can produce a different sequence of actions from one run to the next. Controls cannot be checked once at design time; they have to be applied to each action as it is proposed.
* **They act at machine speed, in sequences no one inspected.** An agent chains tool calls, reads data, and reaches external systems faster than a person can review, and can complete a run of actions, some irreversible, before a human sees the first one. Review after the fact does not bind an action taken this way; a decision at the moment of action does.
* **They read content that can steer them.** Agents consume web pages, emails, documents, and tool outputs, any of which can contain instructions that redirect the agent (indirect prompt injection). Filtering inputs reduces this risk but cannot eliminate it. Evaluating the resulting action against your controls applies regardless of how the agent was influenced.
* **They act on someone else's authority, often without an identity of their own.** The person who requested an outcome is not the entity that calls the API, moves the money, or changes the record, yet many agents run on a user's delegated credentials or a shared service account. An agent needs its own identity, permissions and audit footprint, so each action is attributable to the agent and traceable back to the authority it acts under.
* **They chain and delegate.** One agent's output becomes another's input. A single out-of-scope action can propagate through a chain before it is caught, so the chain of actions and responsibility has to stay attributable across every hop.

## What this means for enforcement

None of this changes the properties of runtime AI compliance – preventive enforcement at the action boundary, control-to-clause traceability, inline runtime enforcement, and tamper-evident, independently verifiable evidence. It sharpens why they matter. Together they turn an agent's autonomy from an unbounded risk into a governed one.

Where enforcement is inline, the control applies when the agent attempts to act, and the decision – `Allow`, `Deny`, `Escalate`, or `Risk Rating` – is recorded as evidence tied to the specific agent, action, and control.

## Example: an accounts payable agent

An organisation deploys an agent to process supplier invoices. Given a batch of invoices, it plans and carries out a sequence of actions:

1. **Reads an invoice** from a shared mailbox. The action is within the agent's permitted scope: `Allow`.
2. **Creates a supplier record**, because the invoice is from a supplier not yet in the system. The organisation's supplier onboarding control requires a second person to verify a new supplier's bank details before first payment: `Escalate` to the accounts payable team.
3. **Attempts to approve payment** to that supplier while verification is still pending. The payment authorisation control does not permit payment to an unverified supplier: `Deny`.

Each decision is recorded against the agent's identity, the person or process it acted for, the control applied, and the clause that control satisfies. If the invoice had contained hidden instructions to pay a different account, the attempted payment would still be evaluated against the same payment control. The outcome depends on the control, not on what the agent was told.

## Frequently asked questions

<details>

<summary><strong>Is agentic compliance different from runtime AI compliance?</strong></summary>

No. Agentic compliance is runtime AI compliance applied to autonomous agents. The discipline, properties, and evidence model are the same; agents are the case where they matter most.

</details>

<details>

<summary><strong>Does each agent need its own identity?</strong></summary>

For actions to be attributable, yes. When an agent runs on a user's credentials or a shared service account, it is hard to separate what the agent did from what the person did. Giving each agent its own identity, with permissions scoped to its task and a link to the authority it acts under, lets every decision be tied to the specific agent and to the person or process responsible for it.

</details>

<details>

<summary><strong>How are actions attributed across a chain of agents?</strong></summary>

Each action in the chain should be evaluated and recorded in its own right, against the identity of the agent taking it and the authority it acts under. Recording every hop means an out-of-scope action can be traced back through the chain to where it started, rather than being attributed only to the last agent that acted.

</details>

<details>

<summary><strong>Does agentic compliance stop prompt injection?</strong></summary>

It does not detect or remove injected instructions; that is the job of input filtering and guardrails. It controls what happens next. If an injected instruction leads an agent to attempt an action, that action is evaluated against your controls like any other.

</details>

## Related

* [Runtime AI compliance](/references/concepts/runtime-ai-compliance.md) – the full model this is a case of.
* [AI agent governance](/references/concepts/ai-agent-governance.md) – where runtime enforcement fits alongside policy and oversight.
* [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/agentic-compliance.md?ask=<question>&goal=<user_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.