Technical Brief

Can you prove what your AI agent touched?

The four questions every security review asks about AI agents — and the architecture that answers them with evidence, not screenshots.

14 min read • September 2026 • Covers release 0.2.15

Somewhere in your organization an AI agent holds legitimate credentials and takes actions: reads a database, calls a payment API, posts to a customer ticket, emails a report. When your security review, auditor, or incident commander asks the four questions, most teams can answer none of them with evidence:

  1. What was this agent allowed to touch, and who approved that?
  2. What did it actually touch — and what was inspected before it left?
  3. Can you stop it right now, without touching the application?
  4. What proof do you have, after the fact, that all of the above happened?

Network controls can't answer these — agent traffic looks like the application's own TLS. Appliance logs can't — they see endpoints, not intent or approval. LLM-provider logs can't — they see prompts after the fact, not the boundary. And screenshots of a dashboard are not evidence.

This is the Kavros answer: a self-hosted governance plane that sits at the enforcement boundary for AI agents, employee AI chat, and scheduled AI workflows — pre-approving what AI can touch, inspecting what leaves, and producing cryptographic evidence of every decision. It also states plainly what Kavros does not claim, because a governance vendor whose pitch is honesty about boundaries should be held to that standard.

Why the controls you already have don't answer the question

Observability is not enforcement. Tracing and logging tools record what happened. They cannot stop a request that shouldn't happen. By the time a dashboard shows the exfiltration, the data is gone.

The agent's credentials are legitimate. The agent uses real API keys and real database access. From the network's point of view, a manipulated agent is indistinguishable from the application it runs in. Trusting the host process is trusting the thing most likely to be manipulated — untrusted content (a ticket, a web page, a document) is exactly what steers agents.

Prompt logging creates a second problem. Copying every prompt and response into an observability pipeline centralizes your most sensitive data in a new place — now with its own access problem, retention problem, and compliance problem.

Dashboards are not evidence. A screenshot has no signature, no chain of custody, no way to show what policy version was in force at decision time.

The gap is a dedicated boundary: something between the AI and the world that can say no, and prove why.

The chain: propose → approve → sign → enforce → meter → prove

 intent            governance                 enforcement               evidence
┌────────┐   ┌───────────────────────┐   ┌──────────────────┐   ┌──────────────┐
│ agent / │   │ control plane         │   │ data plane       │   │ audit trail  │
│ chat /  ├──▶│ propose capability ──▶│──▶│ Nitro Enclave    ├──▶│ hash-chained,│
│ workflow│   │ human approval        │   │  policy verify   │   │ exportable,  │
│         │   │ Ed25519 signature     │   │  DLP inspection  │   │ attested     │
└────────┘   │ revision pinned       │   │  allowlist match │   └──────────────┘
             └───────────────────────┘   │  metering        │
                                         └──────────────────┘
  1. Propose. A capability (a tool, a database surface, an egress target) is proposed — by an engineer, or by the workflow generator itself. Proposals are metadata: never raw credentials, never free-form SQL.
  2. Approve. A human approves. Approvals attach to the capability and are audited with actor, time, and hash-chain entry. An agent cannot approve itself, and a workflow cannot widen its own scope.
  3. Sign. The approved runtime policy is signed with Ed25519. The signing key lives on the control plane; the fingerprint is verifiable by any client, offline.
  4. Enforce. The data plane's AWS Nitro Enclave verifies the signature against its baked trust anchor, checks the target against the allowlist, and runs DLP inspection on content before any bytes leave. Denied means denied: nothing reaches the target, and blocked content is never forwarded or stored.
  5. Meter. Every allowed call is attributed — workload, user, team, run, model, cost. Spend attribution and usage quotas are enforcement primitives, not analytics afterthoughts.
  6. Prove. Decisions, approvals, DLP events, halt/resume actions, and attestation documents land in a hash-chained audit trail with exportable evidence packs.

Signed policies, human approvals, no self-approval

The runtime policy is the contract: which targets, which data surfaces, which limits. Three properties make it trustworthy:

Ed25519-signed. The enclave verifies the signature before enforcing a policy. An unsigned or tampered policy — including one edited by a rogue insider with database access — is rejected outright. Policy signing keys are generated per deployment; the public key is what your team pins. The Kavros CLI verifies any policy or workflow bundle against it, offline:

$ kavros verify-bundle workflow.kavros-bundle.json \
    --public-key "$CP_POLICY_PUBLIC_KEY"
Signature valid (Ed25519, key sha256:71c28434…)

Revision-pinned. Every published tool and workflow is a numbered revision. What ran is recorded against the exact revision that was approved — so "what was in force at decision time" has a precise answer.

Human-gated. Approvals are audited actor+time and cannot be issued by the workload itself. This matters most for agentic workflows: a chat-generated workflow enters a draft lifecycle, composes only already-approved capabilities, and cannot elevate its own privileges. Workflow drift is caught two ways: a capability change under an approved revision is flagged for review at the publish and scheduling gates (runs continue under the signed revision until a human re-approves), and source schema drift suspends the capability — every call refused before any query executes.

The enforcement boundary: an enclave, not a process

The data plane runs its decision engine inside an AWS Nitro Enclave — a hardened, isolated VM on the same host with no persistent storage, no operator shell, and no network path of its own beyond the request path. The component that says "yes" or "no" to egress is not the same process the agent could influence. It runs from the release-built image, and its identity is measurable.

Attestation. Every decision can carry a Nitro attestation document — the COSE structure signed by the Nitro security module, chaining to the AWS certificate, anchoring to the enclave image that your release actually built. In practice: the evidence you export includes proof that the decision was made by the code you shipped, not by whatever is running today.

DLP before egress. Content inspection runs inside the boundary before the request leaves: card-number patterns, secrets/key formats, custom rules. Match → block (nothing leaves) or redact (rewritten before send) — per your rules, applied to agent egress, employee-chat prompts, workflow artifacts, and outgoing email alike. DLP evidence records the rule and a redacted match — enough to verify the decision, without storing the sensitive payload.

The credential story. Workloads authenticate with a workload API key + ID. Provider API keys never belong to the agent — upstream provider headers are attached only after policy approval on the governed path, or held by the control plane's managed inference. An agent that is fully compromised still holds exactly one revocable credential and can only reach what the signed policy allows.

The kill switch, and the evidence behind it

Halting is enforced outside the agent: the data plane refuses every request from a halted workload — quoting the operator's stated reason — until an administrator resumes it. No application redeploy, no key scavenger hunt, no "hope it behaves."

A halt produces a critical incident, an audited action (actor + hash-chain entry), and block events for every request the workload attempts while halted. Resume is equally audited. In our deployment rehearsal this full loop — register → allowed call → halt with reason → blocked attempt → resume → evidence read-back — completed in one sitting with every artifact verified afterward.

The same identity state covers usage-quarantine (a workload over its policy limits stops at the boundary) and revocation (a leaked key stops working everywhere, immediately). Block responses carry a plain-language reason naming what actually happened — "halted by admin@yourco: <reason>", not a generic error — because an on-call engineer who can't tell a halt from a quota trip will route around your controls.

One plane for agents, employee chat, and scheduled workflows

Autonomous agents — the workload contract: signed allowlists, typed capabilities, halt authority, per-run evidence.

Employee AI chat — prompts are DLP-inspected before egress (a card number pasted into a chat is blocked or redacted before the model ever sees it), BYOK provider keys are per-team and never held by employees, URL fetches go through the same signed allowlist, and every conversation's usage is attributed to a user and team.

Scheduled AI workflows — every workflow runs as a signed revision: pinned data scope (column-level allowlists), governed skill queries (read-only, row-capped), artifacts inspected by DLP before download, destinations (email/Slack/files) delivered through the governed outbox — never by the workflow itself. Scheduled runs are halt-able mid-flight; source schema drift suspends the capability — refused before any query executes — and capability changes under an approved revision are flagged for review at the governance gates.

Governed model access — instead of agents holding provider keys, the control plane routes model calls per workload/team: model allowlist, daily cost limits, fallback and cost-aware routing, Anthropic-compatible API, metered per call.

What Kavros claims — and what it does not

Security buyers should distrust vendors who skip this section.

Kavros claims:

Kavros does not claim:

Every claim in this article maps to shipped behavior in release 0.2.15 (September 2026), verified during a fresh-account deployment rehearsal whose pass criteria are recorded in our public deployment checklist. Ask us for the link.

Twenty minutes, one workload

The right next step is a 20-minute architecture assessment: bring the one AI workload you'd most want governed — its tools, its data, its egress — and we'll walk exactly what Kavros would and would not protect, what your policy would say, and what your evidence would show.

That's the product: everything here is verifiable — the signed release manifests, the attestation chain, the offline CLI. Don't take a vendor's word for it. Ours included.

Watch it enforced in the sandbox Book the 20-minute assessment