What compliance evidence do you need for AI agent activity?
Auditors don't want your system prompt. They want evidence that a control existed at the point of risk, that it was evaluated before it was enforced, that it operates and produces decisions with reasons, and that someone owns it and changes it deliberately.
A record of what your agent did covers part of one of those. What is usually missing is a record of the decisions your controls made on each action.
What an auditor is actually asking for
"How do you govern your AI agents?" isn't a question about model behavior. It decomposes into the four asks in the following table.
| The ask | What satisfies it | What does not |
|---|---|---|
| A control exists at the point of risk | The check is in the code path of the consequential action, shipped in the same change as the tool | A policy document, or a prompt instructing the model to behave |
| It was evaluated before it was enforced | Dry-run decisions recorded against real traffic, before the rule started blocking | An assertion that the threshold was chosen carefully |
| It operates | Decisions with allow, deny, or error conclusions and reasons, retrievable per action and per identity | Application logs of what the agent did, which show outcomes but not the control's decisions |
| Someone owns it | Rules in reviewed code, thresholds changed deliberately through a named process | Configuration whose history nobody can account for |
The evidence a runtime decision produces
Each Arcjet decision records an allow, deny, or error conclusion, along with the rule that fired and the reason. DRY_RUN is a rule mode, not a fourth conclusion: a dry-run denial is recorded without changing the conclusion to deny. Guards add a label naming the action, such as tools.issue-refund, and a metadata map that you populate with the context that matters. If you pass a correlationId, then Arcjet ties the decision to the workflow run that produced it. That identifier is for reconstruction; it doesn't change the allow or deny.
That maps onto the four asks directly. The control exists because the check is in the code path, in the same pull request as the tool. It was evaluated first because dry-run results are recorded too, which makes "we measured before enforcing" demonstrable rather than asserted. It operates because decisions carry reasons and are retrievable per action and per identity. Ownership holds because rules live in reviewed code, and Guard remote policies (a labeled-action system) let a security team change allow/deny lists, length, membership, prompt injection, and local sensitive-info without a deployment. Token-bucket stays in application code.
Keep metadata to server-controlled values: authenticated user and team identifiers, enumerated types, status codes, amounts. Never include user-authored free text. Downstream consumers treat metadata as untrusted, and it is the part of a record most likely to leak something.
Retrieve the evidence
Use the tools that match the enforcement path.
Console filters by time and conclusion. Request decisions search by host, path, or request ID. Guard decisions have their own activity view.
CLI. For protect() on HTTP routes: arcjet requests list, arcjet requests details --request-id <id>, and arcjet requests explain --request-id <id>. For guard() on tools, MCP, and jobs: arcjet guards list, arcjet guards details, and arcjet guards watch, which streams live guard activity. arcjet analyze dry-run-impact is the pre-enforcement picture for request remote rules.
MCP server. Request path: list-requests, get-request-details, explain-decision. Guard path: list-guards, get-guard. get-dry-run-impact remains the request-rule promotion check.
Be precise about the limits
Arcjet retains decision history according to your plan's log retention (up to 30 days on the Growth plan; longer on Enterprise), and there is no bulk export and no SIEM integration. Arcjet is where you demonstrate that a control operated and why, over a recent window. Your own logging and retention remain your long-horizon record.
Pair them, and don't assume either covers the other. If your obligation requires seven years of retained evidence, then your logging pipeline meets that obligation, and the runtime decision record is a live operational view rather than the archive. Anyone describing this as an audit trail in the archival sense is overclaiming, and an auditor who probes it finds the gap.
The practical pattern is to emit your own event at the point where you act on a decision, carrying the decision identifier, into whatever system already holds your long-term records. That gives you the durable copy under your own retention policy, with a pointer back to the full context while it is still available.
The platform half
Evidence about your controls helps only if the platform enforcing them is itself in scope.
Arcjet has completed a SOC 2 Type 2 examination covering Security, Availability, and Confidentiality with an unqualified opinion, with the report available through the Trust Center.
Because sensitive-information inspection runs locally and the raw request body is never transmitted, your assessment doesn't have to account for protected data leaving your environment for a third party to check it. That removes a transfer question from the analysis rather than answering it. For detail about which controls run locally and which call out, see keeping security inspection local.
Checklist
- Put the control in the code path of each consequential action, not in a document.
- Run in dry run first, so the pre-enforcement measurement is itself recorded.
- Label every check with the action it protects, using a stable slug.
- Populate metadata with server-controlled values only.
- Tag decisions with the workflow run through a
correlationId. - Emit your own event carrying the decision identifier into your long-term log store.
- Know your plan's retention window (up to 30 days on the Growth plan; longer on Enterprise), and don't describe the decision record as an archival audit trail.
- Keep threshold changes deliberate and attributable.
Where Arcjet fits
Compliance evidence for agents is split between two kinds of tooling. Governance and posture platforms such as Cranium and Refractal describe your AI estate and its controls. Observability platforms record what the agent did.
Arcjet contributes a narrower and often missing piece: the record of what your enforcement controls decided, per action, with the rule and reason, including dry-run decisions from before enforcement was switched on.
Its limits are specific. Retention follows your plan (up to 30 days on the Growth plan; longer on Enterprise), there is no bulk export, and there is no SIEM integration. That makes it a live operational view rather than your archive, so pair it with your own logging for anything with a long retention obligation. A SOC 2 Type 2 examination covers the platform itself, with the report in the Trust Center.
Learn more: Security and compliance · Architecture
Frequently asked questions
What compliance evidence do I need for AI agent activity?
Evidence that a control existed at the point of risk, that it was evaluated before it was enforced, that it operates and produces decisions with reasons, and that someone owns it and changes it deliberately. A record of what the agent did covers only part of the third.
How long is Arcjet decision history retained?
It follows your plan's log retention, up to 30 days on the Growth plan and longer on Enterprise, with no bulk export and no SIEM integration today. That makes it a live operational view rather than an archive, so pair it with your own logging and retention for anything with a long-horizon obligation.
Can I describe Arcjet decision records as an audit trail?
Not in the archival sense. Describe them as evidence that a control operated and why, over a recent window. The durable copy belongs in your own logging pipeline, ideally carrying the decision identifier so the two can be joined.
How do I retrieve Guard decisions versus request decisions?
Use Guard tools for tool, MCP, and job decisions: CLI arcjet guards list, details, and watch, and MCP list-guards and get-guard. Use request tools for HTTP request decisions: arcjet requests list and MCP list-requests, get-request-details, and explain-decision.
How do I demonstrate a control was measured before enforcing?
Run it in DRY_RUN mode first. DRY_RUN is a rule mode, not a third conclusion: dry-run denials are recorded without changing the allow or deny. That makes the pre-enforcement measurement demonstrable rather than asserted.
AI runtime security in your code
Protect your AI agent workflows with Arcjet
Get allow, deny, and redact on agent actions before the side effect.