Proxaradocs
Guides/Platform

Agent governance

A durable identity for every AI agent on the device, and the per-agent controls the firm sets from the console: observe, restrict, block, retire, or stop one agent, all enforced on the device.

Updated July 2026

An AI agent is more than a chat window. Coding assistants, desktop AI apps, and tool-calling agents run on their own, call other tools, and keep working while no one is watching. A person may run several at once, and the same tool can behave very differently depending on where it runs. Proxara gives each agent its own durable identity and lets the firm govern one agent at a time: observe it, restrict it, block it, retire it, or stop it now. Every decision is enforced on the device at the network layer, and each one joins the signed record.

One agent, one identity

The device resolves each agent to a single stable identifier, built from what it can see: which agent product it is, the employee who owns it, the device it runs on, a fingerprint of its working directory, and how it is being run, whether interactively, on a schedule, in CI, or as a background service. Those signals fold into one identifier that stays the same for that agent across sessions and restarts.

The identifier is deliberately steady. A rotated API key or a fresh session does not change it, because the credential and the session are recorded as attributes of the agent rather than as part of its identity. Moving the agent to a new working directory does produce a new one, because that is genuinely a different agent doing different work. Everything used to build the identifier is content-free: the working directory is reduced to a hash on the device, and the raw path never leaves the machine. The identity also notes whether the agent presented a person's delegated credential or a machine credential, shown in the console as Delegated, Machine, or unknown.

Agents are recognized by process attribution: the device knows a connection came from a known AI tool because of the process that opened it, so an agent's identity never depends on a fragile string in its traffic.

Governing a single agent

The firm sets one policy per agent from the console. The device pulls the current policies every few minutes and applies them to that agent's own traffic.

ControlWhat the device does
ObserveThe default. The agent's activity is recorded and nothing is held.
RestrictThe agent's traffic flows normally, except a tool call it makes to a blocked MCP server, which is refused at the wire.
BlockEvery request from this agent is refused at the wire with a calm error and never reaches the AI provider. Only this agent is affected; the product stays available to everyone else.
RetireA retired agent is refused the same way. Retirement ends the agent's lifecycle, and its record stays on the register.

Separately, Stop now is a one-shot request rather than a mode. It asks the device to end the agent's running process a single time. The device acts only on a process it has positively matched to that agent at that moment; if it cannot confirm the match, it ends nothing. Once it has acted, it clears the request.

Enforcement on the device

The decision is made on the device, not in the cloud. For each agent request, the proxy rebuilds the agent's identity locally using the same recipe the server uses, looks it up in the policy set it last pulled, and acts. This runs only on traffic that is genuinely an agent acting on its own. A person typing into a browser or a desktop app is never in this path and is never affected.

Refusals are calm. A blocked request returns a normal, provider-shaped error the agent can read and recover from, not a hang or a broken connection. Every failure mode resolves toward observing: an empty policy set, an identity that cannot be resolved, or any lookup error all leave the agent on Observe, which is exactly the behavior before any policy was set. A governance decision is never the reason an agent silently breaks.

Blocked tool servers

When the firm blocks an MCP server, the device enforces it at the live wire for every agent, not only restricted ones. Calls that carry data to a blocked server are refused with a protocol-correct error, so the client surfaces the message and keeps its session; listing and handshake calls keep flowing so nothing wedges on the way in. A restricted agent is refused only when one of its own tool calls targets such a server. The server modes, and how a server is blocked, are covered in the MCP gateway.

The register and the record

Every agent appears in the console on its own the moment its traffic is first seen, in an inventory the firm never has to maintain: the register. Each agent has a detail page with its owner, device, execution context, and recent activity, and the mode and Stop now controls live there. An employee's page lists the agents that person owns, which is also the view used to retire an agent when someone leaves.

Every governance decision is written as one signed audit entry, hash-chained into the same tamper-evident record as the rest of the firm's AI activity, so there is proof of what was set, by whom, and when. Enforced refusals are recorded the same way, and the records are content-free: they carry identifiers and the tool or server involved, never prompt text. A real-time Teams alert can fire when an agent uses, or is refused, an MCP tool.

Scope notes

Coverage today is the agents the device can attribute: desktop AI apps and the command-line agents a firm has enabled, on macOS and Windows. The identity and the register are built from what the device observes. Reconciling an agent against a corporate directory or a provider's own key inventory is not part of this layer. As everywhere in Proxara, the records are content-free, and inspection of employee AI use is disclosed to employees as part of the firm's deployment.