Introducing Anchor by Eon

Find every AI agent on your workloads, including the ones that never reach a gateway. Tie every tool call to the exact state of the resource it touched. Revert what an agent or a person did. Built on the backups you already take.

AI agents are now part of the production estate. They read from databases, write to buckets, edit records and open tickets. Some were deployed deliberately, through a platform team, with an identity and a policy. Many were not. A developer’s coding assistant with a database connector is an agent. A CI job that calls a model and acts on the answer is an agent.

Security teams have always dealt with unsanctioned software. What is new is that this software acts on its own, with whatever reach it was configured to have. When it gets something wrong, the damage is already in the data before anyone notices.

Zero trust is the right posture for agents: no agent, no user and no tool is trusted by default, and every call is authenticated and authorized before it reaches a resource. Your MCP gateway already does that. But a call can be authorized and still be wrong, because the agent misunderstood the task, or because the agent was never registered in the first place. Zero trust tells you how to gate the front door. It has never had a step for putting the data back.

Today we are introducing Anchor, the recovery step for zero trust. Anchor ties every operation to the state of the data just before it, and can return you to that state.

Anchor does three things:

• Discover: Every agent on your workloads, registered or not. An agentless inventory built from your Eon backup snapshots, showing which agents are installed on which hosts and what each is configured to reach.
• Audit: Every tool call, pinned to the recovery point that holds the resource’s state at that moment.
• Revert: Any audited operation, on request and behind approval.

Throughout this post, Eon is the platform and the data it holds. Anchor is the agent product built on top of it.

Discover: The agents that never reach the gateway

A gateway governs what passes through it. Not every agent will. Agents installed directly on enterprise workloads, on a build host, a developer VM or a container, operate from inside the cloud account and call resources with whatever credentials the host already holds. They never pass through any gateway, and no registration process finds them.

Every protected workload is already captured as a point-in-time snapshot, and agents leave the same footprint on disk as any other software. Anchor scans those snapshots for agent assets: coding assistants, local model runtimes, and the connectors that link them to your systems. Nothing is installed on production, no credentials are used against it, and an agent cannot evade a scan of a copy it never sees.

Because Eon already maintains an inventory of your data and a classification of what it contains, the two join immediately: this coding agent, on this build host, has a connector to that production database, which holds regulated personal data, and runs with approval prompts disabled. That is a risk register, not a list. It is also the shortlist of agents to bring under the gateway next.

Audit: Every operation anchored to a recovery point

Most organizations already have an MCP gateway. Some run a security product in that role. Others use the one their cloud provides: Amazon Bedrock AgentCore Gateway on AWS, the AI gateway in API Management on Azure, Apigee on Google Cloud. Each authenticates the calling principal against your identity provider and authorizes every tool call before it reaches a resource. Anchor does not ask you to replace any of it.

What Anchor adds is the Auditor. It reads the gateway’s logs and the model provider’s invocation logs and, for every operation, works out which resource was touched, how sensitive its data is, and which recovery point holds that resource’s state at that moment. Every cloud gateway exposes the two attachment points this needs: a log stream the Auditor can read, and a policy or interceptor slot where Anchor can sit in the request path when you want it to.

The request side is the same on every cloud: the hook sees the principal and the full tool arguments before the tool runs, which is enough to resolve the resource and pin the recovery point. The response side varies. AWS hands the interceptor the tool result. Azure keeps the response streaming, so the outbound policy sees status and headers rather than the body. Apigee logs the response after it has been sent. In each case the Auditor closes the record from the gateway’s own log when the hook cannot.

The gateway is not the only place a tool call leaves a trace. Every call an agent makes to a model passes through an LLM provider, and the provider’s invocation logs record the model’s response, including the tool calls it decided to make and the arguments it chose. The Auditor consumes those logs too: Amazon Bedrock model invocation logging on AWS, Azure AI Foundry diagnostic logs on Azure, Vertex AI request-response logging on Google Cloud, and the request logs of the frontier providers where they expose them. This closes a gap the gateway cannot. An agent that runs its tools locally, such as a coding assistant on a developer VM with a direct database connector, never passes through an MCP gateway, but it still asks a model what to do. The provider’s log shows the tool call the model returned, which is enough for the Auditor to resolve the resource and pin its recovery point. The provider log records what the agent asked for. The gateway confirms what was done. The provider log also captures something the gateway never sees: the prompt and the model’s reasoning that led to the operation, so an incident record says not only what the agent did but why it thought it should.

The result is one record per operation: who called, which tool, doing what, to which exact resource, against which recovery point. That record is what makes the next section possible.

Revert: Undo, for agents and for people

Detection tools tell you something happened. Gateway logs tell you a call was made. Neither can hand you the data as it stood a moment before. Eon can, because Eon holds it.

The recovery point is recorded as the operation is seen, not reconstructed weeks later in an investigation. It works the same way whether the operation came from an agent or from a person using the same tools through the same gateway or model provider such as Bedrock. An engineer who deletes the wrong folder gets the same undo as the agent that did it on their behalf.

Reversal is selective. Affected paths are restored in place at file, object or row granularity, leaving everything else as it is. For databases, point-in-time recovery narrows the window to seconds. For files and objects, the window is the interval between snapshots.

Undo is not a feature we had to invent for agents. It is what a backup platform already is, connected to the moment the change was made.

What is different about this approach

• The recovery point is known at the moment of the call. Reconstructing what the data looked like before from logs is an investigation. Recording it as the operation happens is an undo.
• Coverage does not stop at the gateway. The scan finds the agents installed on workloads and operating from inside the account, including the ones nobody knew about.
• Reach and sensitivity come from one source. Joining what each agent can reach to what Eon already knows about your data needs no second product and no second integration.
• One undo for agents and people. The same mechanism reverses a mistaken human action and a mistaken agent action, because both arrive through the same gateway or model provider and touch the same data.

Get a demo