AI coding agent admin guide·verified October 21, 2026

see what ai coding agents did on developer machines

Sessions, tool calls and policy decisions from every developer machine in one place, so an incident traces back to an agent session and a machine.

the short answer

Install a hook-based client on every developer machine that reports each agent session, tool call and policy decision to a central console. You get the full trace of any session, decisions you can filter by machine, and SQL over everything. For history from before you connected, a local audit scans the agent logs already on each laptop. It is how you answer “which agent ran that command” when CloudTrail only shows the developer’s SSO session.

Unit of record
Session, made of events (model calls, tool calls, policy decisions)
Fleet view
Admin → enforcement: every enrolled machine, its deployment and last check-in
Decision view
Observe → policy: blocks, block rate, unguarded actions, activity while paused
Past history
failproofai audit scans local agent histories offline
Privacy control
--no-transcripts keeps content local, still reports decisions

The Visibility Gap

Infra teams can tell you every API call made in their cloud accounts. Few can tell you how many of those were generated by an agent, which agent, from what prompt. Once a whole engineering team runs agents, the honest answer to “what are our agents doing” is usually “we find out from CloudTrail when something breaks”.

What You Can See

ViewAnswers
Admin → enforcementWhich machines are enrolled, what policies each runs, observe or enforce, last check-in
Observe → SessionsEvery agent session; filter by environment, status, agent, session ID, and score or metric ranges
Session traceThe ordered model calls, tool calls, errors and decisions in one session
Observe → policyEvaluated actions, blocks, block rate, Cloud decisions, unguarded actions and activity while paused; filter to one machine
Observe → EventsThe live stream as it arrives
Observe → ErrorsRepeated errors grouped by type, agent, tool or time, with the sessions behind them
Analyze → Queries and DashboardsSQL over sessions, events and evaluations: top denied commands, agents touching AWS
Failproof AssistantAsk in plain English; it runs the queries and opens the sessions

History from Before You Connected

failproofai audit scans the agent histories already stored on a machine (Claude Code, Codex, Copilot CLI, Cursor, OpenCode, Pi, Hermes, OpenClaw, Factory, Devin, Antigravity and Goose), replays the tool activity through the built-in policies, and opens a local results view at http://localhost:8020/audit. The scan itself needs no account or network connection. failproofai audit --schedule 7 --email reliability@example.com repeats it weekly and emails the findings; that first setup signs you in when needed.

Correlating with CloudTrail

  1. Start from the CloudTrail event: time, eventName, and the role session name (often the developer’s email under SSO). Route 53 events are in us-east-1.
  2. In Failproof, filter Observe → policy to that person’s machine, or filter Observe → Sessions by environment and agent, around the event time; open the linked session.
  3. Find the Bash tool call containing the matching command or SDK call. The session shows the prompt that led to it.
  4. Write the policy that would have stopped it, backtest it against the same traffic in the policy editor, and deploy it in observe mode.

From the Terminal

--since accepts 15m, 1h, 6h, 24h, 7d or all; use --from and --to for other ranges. --all paginates only up to --limit, which defaults to 50.

fp sessions --env production --since 24h
fp events --since 1h --event-type hook_completed
fp --json events --full --session-id <session-id> --all
fp agent ask "Which machines ran aws route53 commands from an agent this week?"
fp guardrails summary --since 7d      # session-only: needs fp login
fp fleet list                         # session-only: needs fp login

Privacy and What Is Collected

  • Connecting a machine sends transcripts by default, because traces and audits depend on their content.
  • --no-transcripts keeps prompts, file contents and terminal input local; hook activity and policy decisions are still reported.
  • Organizations isolate sessions, users and keys; machine keys need events:add and policies:pull.
  • Turning transcript capture off changes what an investigation can prove. Record that decision.

FAQ

Does visibility require enforcement?

No. You can connect machines with only the always-on guard enforcing and use the traces alone. Many teams start that way for a week.

Can developers see each other’s sessions?

Visibility is organization-wide: members whose permission set includes read access see the organization’s sessions. Access is set by permission set (read-only, standard, admin), and the docs describe no per-developer session restriction, so choose permission sets deliberately.

Is there an audit trail of policy changes?

Every Cloud deployment to a machine is a numbered generation with history, and every policy publish is an immutable version.

Sources

Checked against the sources below on October 21, 2026. Harness settings, hook capabilities and cloud features change between versions.

  1. Failproof AI docs: Sessions overview
  2. Failproof AI docs: Read a trace
  3. Failproof AI docs: Policy decisions
  4. Failproof AI docs: Audit local agent history
  5. Failproof AI docs: Queries
  6. Failproof AI docs: Failproof Assistant
  7. Failproof AI docs: Cloud CLI reference
  8. Failproof AI docs: Deploy a policy
  9. Failproof AI docs: Settings and security
  10. AWS docs: Logging Amazon Route 53 API calls with AWS CloudTrail