What do CISOs mean by audit logs for AI agents?

They mean a per-decision record that survives the agent: inputs, decision, downstream effects, and the scope that authorized it. One Postgres table, one row per decision, kept for 13 months minimum. The record includes the actual data the agent saw at decision time, frozen, not a pointer to a table that might have changed. Total cost: under $5/month for 17 agents.

How do you scope permissions for an AI agent?

Each agent gets a named scope mapping to allowed actions. Load it fresh at run time from a secrets manager. Example: the outreach agent can send emails to cold leads but cannot see payment data. The CRM agent can update tiers but not contracts. No agent shares credentials with a human admin. Use short-lived tokens (under 60 minutes) and rotate credentials on a 30-day schedule.

What's a rollback story for agents?

Pattern one: stage high-impact actions with a hold_until timestamp. A second agent or human approves inside the window (5 minutes for email, 60 for contracts). No approval = auto-cancel. Pattern two: document the reverse-action at write time, not incident time. Refunds that aren't reversible get human approval before execution.

What are the seven controls for agentic AI security?

Scoped credentials per agent, audit log per decision, write-path safety with hold windows, secret rotation on schedule, prompt-injection containment, rollback design at write time, and a written data-residency policy. Together they answer what your CISO, SOC 2 reviewer, insurance underwriter, and privacy team will actually ask for.

Do you need an AI governance platform to pass security review?

No. Vendors sell AI governance platforms for $30-60k/year that wrap the seven controls above. You can run them on Postgres + AWS Secrets Manager + IAM + a 200-line audit-log service for under $30/month. The controls are the thing the platform delivers, not vice versa.

Security and compliance in agentic AI deployments: the seven controls a CISO actually wants

Q: What can't a model decide on its own?

A model can't decide what scope it should have, rotate its own secrets, or determine whether a refund needs human approval. These are architectural decisions made by humans, written into the system, and enforced outside the model's reach. The model's job is making good decisions inside the box you built.

Your CISO sent a one-pager last Wednesday. Three lines. "We can revisit agent rollout when there are: audit logs, permission scoping, and a rollback story."

No details. No example of what good looks like. Just the three asks.

This post is what each of those actually means in agent-land, expanded into the seven controls we put in place at VentureIO before our own CISO greenlit the rollout. With examples for each one. Take it into your next security review and use it as a checklist.

TL;DR

Most "AI security" content is generic and unhelpful. Your CISO doesn't need an OWASP slide. They need to see a working audit log and a working permission scope.
The seven controls: scoped credentials per agent, audit log per decision, write-path safety, secret rotation, prompt-injection containment, rollback design, and a data-residency policy.
Each control is small. Each can be built in a few days. Together they pass the security review your CISO is actually running.
None of these require a new "AI governance platform." We run them on Postgres + AWS Secrets Manager + standard IAM. Total ongoing cost: under $30 a month.
The biggest unforced error is letting an agent run with the same credentials as a human admin. Don't.

What CISOs actually mean by "audit logs"

When your CISO says "audit logs," they do not mean Datadog. They mean: a per-decision record that survives the agent, that can be searched, that includes the inputs the agent saw, the decision it made, and the downstream effects.

Example row, in plain English:

2026-05-14T14:22:03Z
    agent: outreach-closer
    run_id: r_8aef
    decision: send_email
    inputs_hash: 4a1f...
    inputs: {lead_id: L_1029, last_touch: 2026-04-30, signal: "...", template: t_v3}
    model: claude-3-5-sonnet@2026-04-30
    output_hash: d2c1...
    output: {to: "buyer@example.com", subject: "...", body: "...", from: "ic@operatoriq.io"}
    downstream_writes: ["email_send:e_3201", "crm_update:c_1948"]
    authorized_by: scope://outreach.send.cold

Every column is something the CISO will eventually ask for in an incident review. The inputs snapshot is the actual data the agent saw at decision time, frozen, not a pointer to a table that might have changed since. The authorized_by field is the named permission scope that gave the agent the right to take this action.

Build this as one Postgres table. One row per agent decision. Keep it for a minimum of 13 months, long enough to cover an SOC 2 review cycle. Total storage cost on Postgres for our team of 17 agents: under $5 a month.

What "permission scoping" actually means

Your agents must not share credentials. The number-one CISO objection is "the agent has admin access," and they are usually right.

Each agent gets a named scope. The scope is a short string that maps to a list of allowed actions. The scope lives in your secrets manager and is loaded fresh at run time.

scope://outreach.send.cold
      - can send: emails where lead_status in {cold, untouched}
      - can read: leads.{name, company, signals, last_touch}
      - cannot read: leads.phone, leads.payment_method
      - cannot write: anything in payments.*, contracts.*

    scope://crm.update.tier
      - can write: customer.tier
      - cannot write: customer.payment_method, customer.contract_terms

    scope://billing.refund.under_500
      - can write: refunds where amount < 500
      - requires: written justification in audit log
      - cannot write: refunds where amount >= 500

The outreach agent cannot see customer phone numbers. The CRM-update agent cannot touch billing. The billing agent's refund power is bounded by a dollar amount. None of these agents share credentials with a human admin.

In implementation, each scope is a database role or an IAM role, depending on which system the action is in. The agent gets a short-lived token at run start, the token expires inside an hour, and the next run gets a fresh one. Standard pattern. The novel part is making sure the scope is named and the audit log records the scope used.

What "rollback story" actually means

The CISO wants to know: if the agent does something wrong, can you undo it?

For most actions, this collapses to two patterns.

Pattern one: dry-run flag with a hold period. Every irreversible action (outbound email, payment, contract change, public post) is staged with a hold_until timestamp. The action lands in a holding table. A second agent or a human approves it inside the hold window. If nothing approves it, it cancels automatically.

HIGH-IMPACT WRITE PATH
    agent → write to staging table with hold_until = now() + 5 min
            ↓
            verifier or human reviews
            ↓
       approve? → execute
       reject?  → cancel, log, notify
       no-op?   → auto-cancel after hold_until passes

We use a 5-minute hold for outbound email, a 60-minute hold for contract changes, and a same-day human-approval hold for any payment over $500. Hold windows are tuned per impact tier.

Pattern two: idempotent reverse-action. Every write the agent makes has a documented reverse-action. CRM tier update: documented reverse is "set tier back to prior value, audit log the reversal." Email send: documented reverse is "send correction email with explicit subject line and update customer notes." Refund: not reversible, therefore staged with human approval.

Document the reverse-action for every write at design time. Not at incident time.

The seven controls, full list

Here is the complete set we run. Each gets one paragraph.

Control 1: Scoped credentials per agent. No agent shares credentials with another agent. No agent runs as a human admin. Tokens are short-lived (under 60 minutes) and pulled from a secrets manager at run start. If an agent is compromised, the blast radius is the scope, not the kingdom.

Control 2: Audit log per decision. One row per agent decision in a tamper-resistant Postgres table. Inputs, model version, output, downstream writes, named scope. Searchable. Retained 13 months. This is what your CISO walks through in the next SOC 2.

Control 3: Write-path safety with hold windows. High-impact actions stage to a holding table with a hold_until timestamp. Verifier or human approves inside the window. No approval, no execution. Default hold for irreversible actions: 5 minutes.

Control 4: Secret rotation on a schedule. Every agent credential rotates on a 30-day schedule. Rotation is automatic. The rotation event is logged. If a credential leaks, the worst-case exposure is 30 days, and most often much less because rotations are also event-triggered after any anomaly.

Control 5: Prompt-injection containment. Inbound text the agent reads (emails, web content, customer messages) is treated as untrusted. The agent's system prompt explicitly states what it will and will not do regardless of what the input says. Critical actions require an additional confirmation from a second agent. We have not seen a successful prompt injection in 8 months of running this pattern; we have seen multiple attempts and they all got caught at the verifier.

Control 6: Rollback design at write time. Every write has a documented reverse-action. The reverse-action is in the same code as the write. If the reverse is non-trivial (refunds, contract changes), the original write is staged and human-approved.

Control 7: Data-residency policy. A written policy that names which model providers can see which data classes. We do not send customer-PII data classes to model providers outside our compliance perimeter. Names, emails, public signals: fine. Payment data, contract terms, sensitive PII: redacted before sending to the model or routed to an in-region provider. The policy is one page. Your CISO will read it.

The "AI governance platform" question

Vendors are selling AI governance platforms in the $30-60k/yr range. Most of them are a wrapper around the seven controls above.

We have not bought one. We run the seven controls on Postgres + AWS Secrets Manager + IAM + a 200-line audit-log service. Total monthly cost is under $30 in storage and compute.

This is not a position against vendors generally. If you're already on a platform that includes these controls and you're using it, great. If you're being told you must buy one before your agent rollout can pass security review, the seven controls above are the thing the platform would actually deliver. Build them.

What this gets you past

Your CISO's checklist for AI is converging across companies. The pattern we've seen in incoming clients:

SOC 2 reviewers ask for the audit log first.
Internal security teams ask for the permission scopes next.
Insurance underwriters ask for the rollback story.
Privacy reviewers ask about data residency.

The seven controls answer all four. They are not unique to AI; they're the same controls you would put around a critical internal service. The difference is that historically, internal services were built by humans who had the institutional context to be careful. Agents do not. So you put the controls in the architecture instead of trusting them to the operator.

What you cannot delegate to the model

A model cannot decide what scope it should have. A model cannot rotate its own secrets. A model cannot decide whether a refund needs human approval. These are architectural decisions made by humans, written into the system, and enforced outside the model's reach.

The model's job is to make good decisions inside the box you built. The box is what passes security review.

If you want the seven controls implemented in your agent stack in 21 days, look at our blueprints. See the blueprints. The spec includes the scope template, the audit-log schema, the hold-table pattern, the reverse-action documentation format, and the one-page data-residency policy.

A short script for the CISO meeting

Take this with you.

"We are putting in seven specific controls before this goes live. Scoped credentials per agent, audit log per decision, hold windows on irreversible actions, monthly secret rotation, prompt-injection containment with verifier-confirmation, documented reverse-actions on every write, and a written data-residency policy. I can walk you through each one. Here are the example artifacts for each."

That sentence, plus the seven artifacts, ends the meeting in yes.

If you want the audit log schema, the scope templates, and the one-page residency policy we ship to clients, email me. christine@operatoriq.io. Subject line: "security spec."

Next: the agentic AI playbook for going from $1M to $100M, stage by stage.

Common failure modes we see

A short list of what we see in incoming clients who tried to ship agents without the seven controls.

Shared admin token. Every agent runs as the same service account, with the same admin token. When one agent does something wrong, the audit trail blames "the service account." Nobody can tell which agent actually did it. Fix is Control 1.

Logs in CloudWatch only. Agent activity gets logged, but the logs are stream-style: text lines, no structured fields, no input snapshots, retention is 30 days. Insufficient for any SOC 2 review. Fix is Control 2.

No hold window. The agent's email-send code calls SendGrid directly. The first time the agent makes a mistake, that email is already in the buyer's inbox. Fix is Control 3.

Long-lived API keys. The OpenAI key was created in 2024, has admin scope, and has never been rotated. When the key leaks (it will leak), the exposure window is years. Fix is Control 4.

Direct passthrough of user input to the model. The agent reads inbound customer email and includes it in the model prompt unsanitized. Prompt-injection works on the first try. Fix is Control 5.

No documented reverse-action. The agent writes to the CRM, and nobody has thought about what to do if the write was wrong. The first incident takes 3 hours of human investigation to undo. Fix is Control 6.

PII in third-party model calls. The agent passes Social Security numbers or payment details into a model API outside the compliance perimeter. Privacy review fails the next quarter. Fix is Control 7.

Each of these is the result of treating an agent like an internal tool you control rather than a non-human actor that needs the same architectural guardrails as any other service that touches customer data. The seven controls turn the agent from a liability into something your CISO can sign off on.