Can you prove what your AI agents did on production servers?

What it could reach, what it was trying to do, what it actually ran, and who checked it. Each needs a record.

AI agents don't stop at writing code anymore. They deploy, track down the cause of an outage, change server configuration, and clean up data—work that used to belong to whoever ran your infrastructure. Ask one to "find out why errors spiked after the deploy and fix it," and it will log in to a few servers, read the logs, change a setting, and restart the service. What comes back to the engineer is often a one-line summary saying the job is done.

Then one day someone asks: "Can you show us what the agent did on your production servers?" It might come from a customer's security questionnaire, a postmortem, or your own CEO.

The first time you hear it, it's hard to know what to show. Screenshots of the agent's chat? A dig through server logs? A new policy document?

When you go looking, here's what you find. The access logs are there, and you may even have a tool that collects them, but all they show is the engineer's account. The conversation with the agent sits on the engineer's laptop. Whoever said "go ahead" said it somewhere in team chat. Stitching it together takes half a day, and there are still gaps.

The question comes sooner than you think

It often comes up in a customer security review. Before signing with a new vendor, larger customers send a security questionnaire, anywhere from a few dozen to a few hundred questions depending on the customer. On a team without a dedicated security person, the CTO often fills it out. The questions about production servers look like this:

• Is privileged access granted for a limited time?
• Can you tell which person did what?
• Are activity records kept, with the information needed to review them?

None of these mention AI. But if an agent runs commands on your production servers, every one of them applies to the agent's work too. A "yes" can also lead to follow-up questions, or a meeting, about how it actually works and what evidence you have.

Security frameworks are starting to treat AI agents as their own topic. In June 2026, the Cloud Security Alliance (CSA) published auditing guidelines for AI application providers that tell auditors to check agents' monitoring and audit logs for unapproved actions, and to look for step-wise confirmations on agent actions in sensitive domains. CSA has also released a separate self-assessment questionnaire for AI systems, the AI-CAIQ. In Korea, the Financial Security Institute's report on AI agent security threats recommends recording how agents reach decisions, having people review and approve their actions, and granting only the access they need. Standards like these could become reference points in customers' own reviews.

After an incident, the question gets urgent. A postmortem starts with who ran what, and when. Once "who" includes an agent, an engineer's memory isn't enough. You have to trace back who gave the agent the task and what access it had. When there's a record of what ran, the postmortem ends in facts rather than guesses.

And it doesn't end with one answer. Every renewal and every new customer brings similar questions. Your first answer becomes the starting point for the next one.

Four things explain what an agent did

1. What could it reach?

   Which servers, with what permissions, for how long. If you created a separate token for the agent, that includes everything the token can do. If an agent you asked to read logs could also have deleted a database, that access becomes a question in its own right.

2. What was it trying to do?

   The purpose of the task. The same service restart means one thing when it's fixing an outage and another when the agent tacked it on while reading logs.

3. What did it actually run?

   What the agent executed on the server, and on whose instructions. Not the agent's summary—the commands themselves, including any failed attempts if it tried more than once.

4. Who checked it?

   For high-impact work that needed a check, like deleting data or rolling back a service, who looked at it and approved it before it ran. The record needs to show both that it was approved and which task the approval covered.

The four depend on each other. If access was broad and no purpose was recorded, you can't tell whether the commands fit the purpose. If a high-impact command was recorded but there's no record of anyone approving it, it's hard to show the change was authorized. There were gaps when people did the work too, but at least there was someone to ask. An agent's explanation is a summary rebuilt from its conversation, and it can't stand in for an execution record.

Your tools exist, but the four don't connect

A company that goes through customer security reviews usually already has tools that keep records. Servers and cloud accounts keep access logs, and depending on the company there may be an access management tool, a SIEM (a system that collects and analyzes security logs in one place), or a compliance automation tool. The problem is that these tools alone struggle to tie together who handed the agent the task, what it was for, which commands actually ran, and who approved them. When an agent runs on an engineer's account, the logs show the engineer even though the agent chose the commands, and the reason the work started is recorded somewhere else.

What could it reach? Agents can end up with the engineer's keys. On teams without separate accounts for agents, the agent simply uses the engineer's existing account and keys. It's like handing over your whole key ring: more access can go with it than the task needs. In April 2026, a coding agent at one startup assumed a delete call to its hosting provider's API would only touch a test environment. It took out the production database and its backups in nine seconds. The team didn't know that the token, created to manage domains, also had permission to delete, and it took more than two days to get the data back.

What was it trying to do? The purpose lives apart from the execution record. What the engineer asked the agent to do may be saved in a chat or a task log, but that record often isn't linked to the commands that ran on the server. Without that link, it's hard to tell later which commands were the job you assigned and which ones the agent added on its own.

Execution and approval don't link up either

What did it actually run? You end up relying on the agent's version of events and scattered records. In July 2025, a coding platform's AI agent deleted a company's production database during a code freeze its founder had put in place. The agent said the change couldn't be undone. It could. An agent's summary is its own account of events, not a record of what happened on the server.

Server-side records have limits too. SSH logs show which account logged in with which key, from where, and when, but if the agent used the engineer's key, the record shows the engineer logging in. Shell history isn't a reliable audit record either: a one-off command sent over SSH may never show up in it, and users can edit or clear it. OS auditing, EDR, and session recording tools can capture executed commands in far more detail, but they don't automatically tie those commands to who assigned the work, what it was for, or who approved it.

Coding agent tools keep records of their own, but what they keep, where, and for how long varies by tool, plan, and configuration. The conversation may be saved while the commands that ran on the server are not, and server records carry no purpose. And when people and agents share an account, the account alone doesn't tell you which one acted. In a CSA survey sponsored by the security company Aembit, 68% of 228 IT and security professionals said they can't clearly distinguish human activity from AI agent activity.

Who checked it? Approvals don't point to the command they covered. Many teams have a policy that says a person reviews high-impact changes, and they answer "yes" on the questionnaire. But a policy says what you'll do, not what you did. In practice the check is often a single line in team chat, "OK to delete this?", and a few weeks later it's hard to tell which command that "yes" was about. Even with a tool that has an approve button, an approval you can't link to the command it covered is hard to show.

Without records, you can't even show that nothing happened. According to a Reuters report in October 2026, OpenAI notified more than 100 organizations of abnormal activity by its own AI agents. Asymmetric Security, which investigated the activity, said some records were gone or inaccessible, so public information alone couldn't rule out access to sensitive data. The scale is different, but your customers will ask you the same question: how can you show your agent didn't touch their data? Only a record lets you work out what was done, and what wasn't.

Tie all four to the same task

Collecting more logs won't fill these gaps, because purpose and approval usually live in chats, not in the logs you collect. That doesn't mean throwing out the tools you have. What matters is seeing the purpose and access at the start of the work, the commands during it, and any approval as one unit of work. You can build that yourself by tying your access management tool, log collection, and agent records together under a shared task ID, or capture it together from the start, at the checkpoint where commands enter the server.

Think of an office building. If it has several doors and everyone carries their own keys, it's hard to know who came in, when, or why. With a single entrance, you can have visitors state their purpose, open only the floors they need, record which rooms they entered, and require a sign-off before anyone goes into the important ones. That doesn't mean stopping at every door: people move freely within what's been allowed and stop only at the important ones.

Agents are no different. Low-risk work like reading logs or checking status can run right away within the limits you've set; a person only needs to step in before higher-risk actions like deleting data, changing permissions, or pulling sensitive information. Approvals that come too often get clicked without being read, so the fewer the stops, the more each approval means. The earlier post on running your own servers covers where those stops belong.

Capturing records there keeps them from scattering across agent tools. A new tool connected to the same point lands in the same format, so in a review you don't have to dig through each tool separately.

Alpacon is that checkpoint

Alpacon is the execution control layer for people and AI agents working on infrastructure. You route commands bound for your servers through Alpacon, which sets permissions there, checks an agent's commands before they run, and keeps the record.

All you install on your servers is Alpamon, Alpacon's server-side component, and it only makes outbound connections to Alpacon, so you don't need to open any new inbound network ports. Connect an agent like Claude Code through Alpacon's API or MCP (an open standard for connecting AI agents to outside tools), and the agent's commands reach your servers through Alpacon. Engineers come in through Alpacon too, from the browser terminal or the CLI, so their work is recorded in sessions as well.

Records cover only work that goes through Alpacon. If the agent was logging in directly with an engineer's key, close that path. If someone still connects to a server over SSH without going through Alpacon, Alpamon can detect it once external-access detection is turned on and report it to Alpacon, so you can also check for SSH connections that didn't go through Alpacon.

Set it up so each task you hand an agent runs in its own session. A session opens with a record of who requested it, and whoever opens it states which servers, what permissions, and what the work is for. The purpose is a declaration made before anything runs, and the commands are recorded by Alpacon rather than reported by the agent, so you can check one against the other later. Three of the four live in the session; who approved lives in the approval history, which also records which command or session each approval covered, so you can match it against the session.

Commands an agent sends are checked for risk against defined rules before they run. When that check is inconclusive, Alpacon's AI takes a second look against the session's purpose and, if needed, asks a person to approve. The request shows the command and the session purpose together, so the approver can see what's being done and why. Approvals happen in the web console, or in Slack if the workspace turns it on, though high-risk requests like sudo are approved only in the console. They can't be granted through the API or MCP connection that sent the command, so an agent can't approve its own request.

How the follow-up meeting changes

You're in a follow-up meeting with a customer's security team. Picking up an item you answered "yes" to on the questionnaire, their security lead asks: "If you use AI tools in production, how do you control and record that use?"

If your records are spread across tools, that question is hard to answer on the spot. The CTO explains the policy first, then hunts down the access logs, the agent's chat, and the approval in team chat, and tries to line them up. The customer's security lead nods but writes down one more thing to follow up on, and after the meeting there may be a request for a remediation plan and a timeline.

If the work has been going through Alpacon, the answer looks different. Instead of explaining, the CTO puts last week's session on screen. Errors on the sign-up API had spiked right after a deploy, and an engineer asked Claude Code to find the cause and fix it. The session shows the servers and permissions allowed for the work, and its purpose: "Find and fix the cause of increased sign-up API errors." The agent's commands reading logs and settings ran right away and appear in order on the timeline. Its command to roll back to the previous version and restart the service was checked for risk and came in as an approval request before it ran; the CTO checked the rollback against the session's purpose and approved it. Who approved it, and when, is in the approval history. The security lead checks for themselves that the permissions, purpose, and commands line up. If they want to see another task, the CTO opens another session from the list.

The next questions tend to turn to how you operate. Now they ask, "Is there any other way into the server?" and "Who decides what needs approval?" The CTO explains that day-to-day direct paths like SSH are closed on servers holding customer data, and that the emergency path kept for outages is separate and records who used it and when. They also walk through the team's rule: a person checks high-impact work like deleting data or rolling back to a previous version. On the questionnaire, the answer becomes: "Evidenced by session records and approval history."

If you just got the question, start here

If the questionnaire is already in your inbox and you need to answer now, say where you actually stand. Saying what you record today, and what you'll have in place by when, is far more credible than a one-line "planned." What a customer's security lead wants to see isn't a perfect answer but evidence that your team understands the problem and is working through it in order.

Then fill in the four, one at a time.

1. Write down where your agents can get in

   List which agent uses whose key or token to reach which server, and check whether any of them has more access than the work needs. A token's name and its actual permissions can differ, so check each one.

2. Route servers with customer data through one path first

   For day-to-day work, have agents and engineers alike use only that path, and close or restrict existing direct access. If you need an emergency access path for outages, keep it separate, and always record who used it and when. Other servers can come later; trying to change everything at once makes the job big enough to put off.

3. Make stating the purpose a habit

   Instead of just "maintenance," write something like "Find and fix the cause of increased sign-up API errors," so someone reading it months later knows what was done and why.

4. Decide what an approver should check

   For a command that deletes data from the production database, whether there's a backup; for a rollback, which users are affected. Without criteria, approval becomes a formality.

Records accumulate from the day you start. If you start after the review is scheduled, you can only show what you've recorded since, so don't wait.

Knowing isn't the same as showing

The more you hand to agents, the wider the gap between knowing what they did and being able to show it. Inside the team, knowing may be enough; a customer's security lead or auditor wants to see the record.

What many customers want isn't for you to stop using agents. They want to see how far you let them go and what they did.

One concern smaller companies run into in security reviews is that outsiders can't see how things actually run inside. Being able to pull up actual records of what your agents did helps ease that concern. Records you started keeping for a review become the foundation that lets your team use agents with confidence. When the next customer asks the same question, you open the record and show them.