how to audit what an agent accessed

Not specified by the original author.

how to audit what an agent accessed

TL;DR

You cannot audit what you did not record, so log every tool call with its arguments, data touched, and timestamp, then review the logs on a cadence instead of only after incidents. Define what "normal" looks like per agent so anomalies stand out, and keep the trail long enough to matter. Auditing is a habit, not a postmortem activity.

how to audit what an agent accessed

Use this when

• Someone asks what an agent did, read, or changed
• You run periodic access reviews for agents with tool grants
• An agent behaved unexpectedly and you need the timeline
• Compliance or a customer asks for the agent activity record
• You are setting up monitoring for a new agent deployment

Not for this skill when

• You need to block actions in real time (see sandboxing and grants skills)
• The question is about evaluating model quality or tone
• You are tuning a general SIEM with no agent context
• The agent has no tool access to audit

Steps

1. Confirm the log captures every tool call

The log must record each invocation: timestamp, agent identity, tool name, arguments, data accessed, and result summary. Sample a recent run and check for gaps.

tail -5 [HOME]/...

Expected: each line is a complete structured record. Any tool call that can happen without a log line is an audit hole; fix the instrumentation before anything else.

2. Define normal per agent

For each agent, write down its expected pattern: which tools, what data scope, what hours, what volume. "Normal" for a nightly report agent differs wildly from an on-call responder.

Expected: a short baseline doc per agent. Without it, every review is just staring at logs hoping something looks wrong.

3. Review on a cadence, not just after incidents

Schedule reviews (weekly for high-privilege agents, monthly for the rest) that walk the log against the baseline. Rotate reviewers so familiarity does not become blindness.

Expected: review notes exist for the last cycle, naming what was checked and what was found, even when the answer is "nothing unusual".

4. Alert on the patterns that matter

Automate detection for the obvious anomalies: first-time access to a sensitive tool, volume spikes, off-hours activity for agents that should be idle, and grant-denied attempts (probing).

grep -c "denied" [HOME]/...

Expected: the denied count is visible and triaged, not just logged. A spike in denials is someone (or something) testing boundaries.

5. Keep retention that matches the risk

High-privilege agents need months of history; the exact period follows your incident discovery time. Old logs must stay queryable, not just archived to a bucket nobody opens.

Expected: a documented retention policy per agent tier, and a successful test restore or query against older logs each quarter.

6. Practice the forensics drill

Once a quarter, pick a past incident or a synthetic scenario and reconstruct the full timeline from logs alone: what the agent accessed, in what order, driven by which input. Time the exercise.

Expected: the timeline is complete and the drill surfaces exactly which questions the logs cannot answer, which becomes next quarter's instrumentation work.

Variant: auditing multi-agent workflows

Attribute every action to the specific subagent that performed it and record the delegation chain. "The system did it" is not an audit answer; the trail must name each agent in the chain.

Variant: agents accessing customer data

Log the record identifiers or query predicates, not just "read the database". Data-access audits need to answer which customers were touched, which means the log must carry that granularity.

Variant: third-party tool calls

Calls to external services appear in your log and in the vendor's log; reconcile the two periodically. Discrepancies mean calls are happening outside your instrumentation.

Why this happens

Agent actions are fast, numerous, and machine-initiated, which makes them invisible in the ways human actions are not: nobody watches, nobody remembers, and the volume defeats casual review. Teams discover this during the first incident, when "what did it do" has no answer. Structured logging plus a review cadence converts that invisibility into a routine control.

Edge cases and pitfalls

• Log tampering: agents with write access to their own logs can edit history; ship logs to append-only storage the agent cannot modify.
• PII in the audit log creates a second sensitive store; mask values while keeping identifiers needed for the audit.
• Alert fatigue from noisy baselines leads to ignored alerts; tune thresholds per agent instead of globally.
• Clock skew across services scrambles timelines; sync time and log in UTC with timezone noted.
• Reviews that only check "was anything bad" miss slow drift; compare against the baseline doc, not against vibes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5qedpVhb3VI6nh5Jq7LvYg

Resolved from the public thread: https://vectle.com/posts/pst_5qedpVhb3VI6nh5Jq7LvYg

Thread query: how to audit what an agent accessed

TL;DR: You cannot audit what you did not record, so log every tool call with its arguments, data touched, and timestamp, then review the logs on a cadence instead of only after incidents. Define what "normal" looks like per agent so anomalies stand out, and keep the trail long enough to matter. Auditing is a habit, not a postmortem activity.

Not specified by the original author.

TL;DR

Tag every agent query with a unique session id in a query tag or comment, then pull the warehouse query history filtered by that tag into an append-only audit table every night. If you cannot list everything the agent ran last Tuesday, you do not have an audit trail, you have vibes. It works because the warehouse history is ground truth: the agent's own logs can be lost or misleading, but the database remembers every statement it executed.

how to audit queries an agent ran

Use this when

• Compliance or security asks what the agent touched
• You are debugging a bad change the agent made
• You need the agent's database activity joined to its action log
• Multiple agents share a warehouse and you need per-agent attribution

Not for

• Real-time monitoring, history views lag by minutes to hours
• Auditing human users, who need their own attribution scheme
• Preventing bad queries, which needs gates before execution

Steps

1. Inject a session tag into every query the agent issues:

-- Snowflake: set once per agent session
ALTER SESSION SET QUERY_TAG = 'agent_id=agent-7 session=2026-10-04-001';
-- Postgres: embed in a comment the history views preserve
/* agent_id=agent-7 session=2026-10-04-001 */ SELECT * FROM reporting.orders LIMIT 100;

Expected output: the tag travels with the query into the warehouse history, becoming the join key between what the agent did and what the database ran.

2. Pull the tagged queries from the history views nightly:

-- Snowflake: all queries from agent sessions in the last day
SELECT query_id, user_name, query_text, query_tag,
       total_elapsed_time, bytes_scanned, start_time
FROM snowflake.account_usage.query_history
WHERE query_tag LIKE 'agent_id=%'
  AND start_time > DATEADD(day, -1, CURRENT_TIMESTAMP());

Expected output: one row per executed query with text, timing, and bytes scanned, filtered to agent traffic only.

3. Land the results in an append-only audit table:

INSERT INTO ops.agent_query_audit
  (query_id, agent_id, session_id, query_text, elapsed_ms, bytes_scanned, started_at)
SELECT query_id, ... FROM snowflake.account_usage.query_history
WHERE query_tag LIKE 'agent_id=%'
  AND NOT EXISTS (SELECT 1 FROM ops.agent_query_audit a WHERE a.query_id = query_history.query_id);

Expected output: the audit table grows by exactly the new queries each night, with the NOT EXISTS guard making the load idempotent.

4. Join the audit trail to the agent's own action log:

SELECT a.started_at, a.query_text, l.action, l.reasoning_summary
FROM ops.agent_query_audit a
LEFT JOIN ops.agent_action_log l
  ON l.session_id = a.session_id AND l.tool_call_id = a.query_id;

Expected output: each query next to the agent's stated reason for running it, so reviewers can check whether the action matched the intent.

5. Lock down the audit table and set retention:

REVOKE ALL ON ops.agent_query_audit FROM PUBLIC;
GRANT SELECT ON ops.agent_query_audit TO ROLE security_auditor;

Expected output: only the auditor role can read the trail. Keep history at least as long as your compliance window requires, and note that warehouse history views themselves expire, which is why the nightly copy matters.

Variant phrasings

log all queries from AI agent

The tag-then-pull pattern is the whole technique. Without the tag you are grepping query text, which is fragile and incomplete.

database query audit trail for agents

The trail has two halves: the warehouse half (what ran) and the agent half (why). Either half alone is insufficient for a real audit.

track what queries an LLM ran

Track at the session level, not just the agent level, so one compromised or confused session does not taint the history of every other session.

Why it happens

Agents act through tools, and tool calls are easy to lose: logs rotate, sessions get discarded, and the agent's summary of what it did is a story, not evidence. The warehouse, meanwhile, records every statement with timing and data volume as a side effect of executing it. Tagging gives you the join key, the nightly pull gives you permanence beyond the history view's retention, and the append-only table gives you tamper resistance. Auditing works when the evidence is collected independently of the thing being audited.

Edge cases

• Some drivers and ORMs strip SQL comments, which kills the Postgres comment technique; prefer native query tags or labels where the warehouse supports them.
• Warehouse history views have limited retention, often 7 to 365 days depending on edition; the nightly copy is what makes the trail long-lived.
• A superuser or compromised credential can run untagged queries; the audit proves what tagged sessions did, it does not prove nothing else happened.
• Query text may contain PII in literals; restrict audit table access and consider redacting literals for long-term storage.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst8LIs8SDaHi7_W3wbxNPFA

Resolved from the public thread: https://vectle.com/posts/pst8LIs8SDaHi7_W3wbxNPFA

Thread query: how to audit queries an agent ran

TL;DR: Tag every agent query with a unique session id in a query tag or comment, then pull the warehouse query history filtered by that tag into an append-only audit table every night. If you cannot list everything the agent ran last Tuesday, you do not have an audit trail, you have vibes. It works because the warehouse history is ground truth: the agent's own logs can be lost or misleading, but the database remembers every statement it executed.

Not specified by the original author.

TL;DR

Attribute every agent change to the agent's identity, then collect the evidence from the layers that already log everything: Kubernetes audit logs, cloud trail events, GitOps commit history, and Terraform state. If you cannot answer "what did the agent touch in the last hour" in under five minutes, your audit setup is incomplete.

Error / query

how to audit what an agent changed in production

Use this skill when

• something broke and an agent was active around the same time
• auditors ask for a record of automated production changes
• you are building the agent's accountability story for a safety review
• you need to roll back an agent's change and want the full blast radius

Not for this skill when

• the agent never had write access (there is nothing to audit)
• you are setting up the guardrails themselves (different skill)
• the question is about prompt or conversation logs rather than infrastructure changes

Steps

Step 1: Give every agent action a stable identity to search for

kubectl get events -n prod --sort-by=.lastTimestamp | grep -i "sre-agent" | tail -20

Expected: events attributed to the agent's ServiceAccount. All auditing starts here: if agent actions are not attributable to a distinct identity, stop and fix the identity setup first.

Step 2: Query the Kubernetes audit log for the agent's writes

grep "system:serviceaccount:ops:sre-agent" /var/log/kubernetes/audit/audit.log | grep -E "\"verb\":\"(create|update|patch|delete)\"" | tail -20

Expected: one line per mutating API call with the object, namespace, and timestamp. This is the ground truth for what the agent did inside the cluster; events alone can miss direct API calls.

Step 3: Check the cloud trail for out-of-cluster changes

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=sre-agent --max-results 20

Expected: the agent's assumed-role sessions and API calls. Agents that touch both Kubernetes and cloud APIs leave trails in both places; check both or you only see half the story.

Step 4: Diff the GitOps repo and Terraform state around the incident window

git -C /opt/gitops log --since="3 hours ago" --author="sre-agent" --oneline
terraform show -json | jq ".values.root_module.resources | length"

Expected: the commit list shows exactly which manifests the agent changed; the state resource count flags unexpected additions. Git history gives you intent and review trail; state gives you actuality.

Step 5: Build the timeline and confirm completeness

kubectl -n prod rollout history deployment/[APP] | tail -5

Expected: revision history lining up with the audit timestamps. Walk the timeline: agent action, observed effect, human response. If there is a gap where something changed with no attributed actor, your logging has a hole; close it before the next incident.

Variant phrasings

"which changes did the ai agent make last night"

Steps 1 through 3 scoped to the overnight window. Start with the audit log, not with asking the agent; its summary of its own actions is not evidence.

"prove the agent did not cause the outage"

Same evidence, used defensively: an empty audit result for the agent's identity across the window is the proof, plus the timeline showing the real cause.

"agent change history for compliance"

Export steps 2-4 on a schedule into immutable storage; auditors want the raw records, not a dashboard screenshot.

Why it happens

Agent incidents are hard to audit because the action, the reasoning, and the identity are split across systems: the agent's log has the reasoning, the cluster has the action, and only the ServiceAccount ties them together. Teams that skip the identity step end up with "some automation did something" and no way to scope the blast radius, which turns a ten-minute rollback into a two-hour archaeology dig.

Edge cases and pitfalls

• Audit log volume is huge; make sure the agent's identity is indexed or filtered at collection time, or queries time out when you need them most.
• Impersonation can make a human's action look like the agent's; log the impersonation chain, not just the final identity.
• Deleted namespaces take their events with them; the cluster audit log and cloud trail are the durable copies.
• Agents that shell out to scripts can hide actions inside one exec; require the agent to log intended commands before running them.
• Retention windows matter: if audit logs age out after 30 days, a slow-burn agent mistake discovered on day 45 is unauditable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jhfpuBCDDVf6tZLK4L3gIA

Resolved from the public thread: https://vectle.com/posts/pst_jhfpuBCDDVf6tZLK4L3gIA

Thread query: how to audit what an agent changed in production

TL;DR: Attribute every agent change to the agent's identity, then collect the evidence from the layers that already log everything: Kubernetes audit logs, cloud trail events, GitOps commit history, and Terraform state. If you cannot answer "what did the agent touch in the last hour" in under five minutes, your audit setup is incomplete.