Enterprises keep asking us three things: which agents are running here, what are they allowed to do, and can we show what they did and why. Algedonic builds runtime security for enterprise AI agents. We find the agents running in your environment, including the ones nobody registered, and we apply policy to what an agent is about to do rather than only to the identity it borrowed. Both of these, Witness and Guard, are in early access. The third layer, Command, is in development. Its job is to bring the other two together.

The three questions an enterprise has to answer before it can trust an AI agent

Your organization has AI agents. You know about some of them.

The agents you know about were built on purpose. The rest turned up: a vendor switched on a copilot in software you already pay for, a team automated something and told nobody, a platform came with agents in the box. Most of these agents arrived through individually reasonable decisions. The control gap appears at the enterprise level: nobody has a complete, continuously updated view.

That missing list is the first of the three questions, and the other two depend on it.

One: what agents are running here?

This sounds like an inventory question, and inventory questions feel solvable. Buy a tool, run a scan, get a list.

It is harder than that, because the agents you built on purpose are the smallest part of what you have. Each of the others arrived through a decision that made sense at the time, and nobody was keeping a running total.

Some of it is shadow AI: agents and tools nobody registered or reviewed. Knowing they exist is half the answer. The other half is knowing whose authority each one carries, because an agent acts with permissions that belong to a person or a service account. That inheritance decides what it can reach.

Which is why this question comes first. You cannot apply a policy to an agent you do not know about.

Two: if an agent does something it should not, does anything stop it?

An agent that behaved correctly on the day it shipped can drift from what it was built to do. Nothing about its credentials changes while that happens. The permissions still check out. What the agent is doing with them has moved. Your monitoring may catch it. But watching and stopping are different jobs.

Your access controls work. They were built for two kinds of actors and they handle both well: people, who have judgment, and services, which do not, but which do the same thing every time. An agent is neither. It is software that decides what to do and then does it. It holds a credential like a service and chooses like a person. Your access controls were built for the service half of that.

A permission is a decision made once, about an agent that keeps changing. The agent passes the check on a routine Tuesday and on the day it does something nobody anticipated.

So the question is not whether an agent is allowed to act. It is whether this particular action should happen, now, in this context. A fixed permission cannot answer that.

Three: if something goes wrong, can we prove what happened and why?

A log records that something happened. When a review starts, the question is why it was allowed to happen, and that is the part the log does not hold.

This is the question your regulators and your board eventually ask, and it is the only one of the three that has to be answered before anybody asks it. Plenty of tools will reconstruct a sequence of events after the fact, and they can only work with what was written down while it happened. If nothing captured why an action went ahead, no amount of reconstruction will produce it.

So the record you need cannot be added later. It is made while the action happens, by the discovery that saw the agent and the decision that let the action through. That record can tell you why the action was permitted or refused, and on what basis. It cannot reveal an agent's private reasoning or establish intent with certainty.

Who pays when this goes wrong

The exposure gets filed as a security problem. It is one. But the bill does not always arrive at security. The three scenarios that follow are composites, built from conversations rather than from any single company, and in each of them the bill arrives somewhere different.

Finance: the spending nobody budgeted. A bank ran two agents in tandem. One wrote a database query, the other checked the result and sent it back to be rewritten if it looked wrong. An ambiguous request put them in a loop. There was no retry cap and no ceiling, so they kept going, politely, over a long weekend. Nobody was watching the meter, because nobody had thought to put one there. Somebody in finance found it on the invoice.

Operations: the ban that stopped the line. A firm that assesses vendors at scale built an agent to do it, fetching filings and disclosures from hundreds of external sites on every run. With no limit on how fast it could pull, it pulled at machine speed, breached the providers' terms of use, and got the account blocked. The workflow did not slow down. It stopped. The team went back to doing the assessments by hand while somebody negotiated the account back.

Security: the agent that became a skeleton key. A utility built an agent to work across thousands of devices on its operational network. To reach each service it collected an access token, and it kept them: broad, long-lived, accumulating as it went. One identity ended up holding the keys to the estate. A red team found a path to the agent and, through it, to every connected device. Because they found it, the cost was a weekend of credential rotation and an uncomfortable conversation about architecture. Had somebody else found it first, the cost was control of systems that run physical infrastructure.

In all three scenarios, everything the agent did was permitted. Nothing was positioned to refuse any single action, and a better report afterward would not have changed that.

Where we are today

Witness answers the first question. Across the environments where it is deployed, it discovers agents operating there, including ones nobody registered, and records what they do. It reports rather than blocks, which is where the teams we work with have wanted to start.

Guard answers the second. Before an action is carried out, it evaluates that action in the context the agent is operating in and decides whether it may proceed. It can operate independently of the agent's own code and, in many deployment configurations, can be introduced without requiring changes to that code. An agent that has drifted is the thing being checked, so the check cannot live inside it.

Both Witness and Guard are in early access.

Command is meant to answer the third. It is the coordination layer, and it is in development. Its job is to bring discovery and enforcement together, so that execution can be managed and the full sequence of activity can be followed over time.

If any of this describes your challenges, we would be glad to talk about your environment. algedonic.ai