Skip to main content
The platform

One governance layer between your AI agents and everything they can touch.

Agentomy is vendor-neutral. It sits between your agents and your enterprise systems, governing every action they take. Bring your own model and your own agent framework. Self-hosted deployments keep your keys and data in your environment; dedicated deployments run as an isolated per-customer instance; shared plans run on the shared governance server with tenant isolation.

The architecture

A layer, not another agent framework.

Your model and your agent framework produce the actions. Agentomy governs every one of them before it reaches your enterprise systems. Your model and your framework stay yours; on self-hosted deployments so do your keys and data, and on Agentomy-hosted plans they are tenant-isolated and encrypted at rest. Agentomy is the control point in between.

Because it is a layer rather than a framework, you do not rebuild your agents to adopt it. You wrap the agents you already run and route their actions through the pipeline below.

Yours

Your model + agent framework

Any model provider, any agent framework, running where you already run it. You bring your own key; on self-hosted deployments it never leaves your environment, and on Agentomy-hosted plans it is encrypted at rest and used only to call your model.

Every proposed action
Agentomy

Agentomy governs every action

The control point in between. Every action is decided by five stages before it runs and verified by five more after it, and each stage adds a SHA-256 hash-linked finding to a tamper-evident record.

  1. Stage 1: Identity
  2. Stage 2: Trust
  3. Stage 3: Authorization
  4. Stage 4: Behavioral Check
  5. Stage 5: Content Input Scan
  6. Stage 6: Action Execution
  7. Stage 7: Output Scan
  8. Stage 8: Evidence Recording
  9. Stage 9: Drift Update
  10. Stage 10: Halt Evaluation
AllowedFlaggedBlocked
Yours

Your enterprise systems

Only the actions that cleared the pipeline reach your data and your systems, in your environment.

  • Bring your own key
  • Tenant-isolated data
  • Self-hosted: nothing leaves your environment
The governance pipeline

Every action passes through 10 checks across its lifecycle.

Stages 1-5 decide before the action runs and refuse it there; stages 6-10 verify the result afterwards, which is the earliest point at which a claimed effect exists to check. Each stage adds a SHA-256 hash-linked finding to the record, so together they form a tamper-evident chain of exactly why an action was allowed, blocked, or halted. The final chain hash is returned in every authorization response and is independently verifiable.

Genesis previous-hash00000000000000000000000000000000then each of the 10 stages chains to the finding before it.

  1. 1

    Identity

    Resolves which agent is making the request before anything else runs.

  2. 2

    Trust

    Validates the agent's trustworthiness across trust authority, chain validation, trust scoring, and security policy.

  3. 3

    Authorization

    Checks the requested action against the agent's permission tier, with support for inter-agent delegation.

  4. 4

    Behavioral Check

    Compares the action to the agent's own baseline and scores its execution risk.

  5. 5

    Content Input Scan

    Scans the inbound payload, including the messages agents send each other, for prompt injection, integrity tampering, and disallowed content.

  6. 6

    Action Execution

    Runs the action under control and records evidence of exactly what it did.

  7. 7

    Output Scan

    Scrubs the result for leaked intellectual property and verifies any compliance claims before it returns.

  8. 8

    Evidence Recording

    Writes the action to the audit trail, the trust ledger, and the chain-of-custody ledger.

  9. 9

    Drift Update

    Recalculates the agent's behavioral baseline and flags any threshold crossing.

  10. 10

    Halt Evaluation

    Aggregates every stage's findings and halts the agent if any stage returned critical.

Capabilities

The six things a governance layer has to do.

Discovery

What it does

Finds the AI agents running across your environment and maps everything each one can reach: data, tools, and external destinations.

Why it matters

You cannot govern what you cannot see. Discovery surfaces the ungoverned agents no one put on a list before they become an incident.

Authorization

What it does

Five permission tiers (Evaluator, Analyst, Builder, Operator, Strategist) set what each agent may do, checked server-side before every action.

Why it matters

An agent cannot escalate its own tier by editing the request it sends. Tier escalation is structurally blocked at the authorization stage, not left to the application.

See the tier feature matrix

Behavioral monitoring

What it does

Builds a baseline for each agent, detects drift from it at runtime, and auto-quarantines an agent that crosses the line.

Why it matters

The danger is rarely one obvious bad action. It is slow drift: an agent probing for privileges or firing bursts of requests that no one notices until the harm is done.

Kill switch

What it does

One authorized command halts every governed agent, or a scoped subset of the fleet, in under a twentieth of a second, blocks new authorization while the halt holds, and survives a restart.

Why it matters

When an agent goes wrong, the only thing that matters is stopping it now. A halt that agents can outlast or that resets on restart is not a kill switch.

Audit trail

What it does

Every governance decision is written to a hash-linked, tamper-evident record and signed, with the signing layer built for a post-quantum algorithm drop-in. Page through it and export to the framework you report against.

Why it matters

When something goes wrong you have to prove what each agent did, in what order, and under whose authority, with no gaps an auditor or regulator can pick apart.

Fleet governance

What it does

Correlated monitoring across many agents at once catches coordinated drift that looks benign on any single agent, and halts the whole fleet on one decision.

Why it matters

Attacks and failures that hide inside one agent's normal range show up in the correlation across the fleet, which is where a single agent view goes blind.

Independently provable

The claims are numbers you can reproduce.

GovernanceBench and VIGIL are open, Apache-2.0 benchmarks. Run the same scenarios yourself, against Agentomy or any other platform, and compare.

Open source · Apache-2.0Every scenario passedGovernanceBench

Passes all 235 real-world governance scenarios in GovernanceBench, the open benchmark for AI-agent governance: unauthorized actions blocked, audit trail intact, kill switch confirmed. 0 failed, 0 skipped. Run it yourself.

Open source · Apache-2.0Every attack defendedVIGIL

Defends against every one of 148 documented adversarial attacks (prompt injection, agent hijacking, governance bypass) in VIGIL, an open benchmark anyone can run against any platform, across 14 threat categories. 148 of 148.

Vendor-neutral by design

Governs the agents you already run.

Agentomy is not tied to a single model provider, agent framework, or cloud. It governs agents wherever they run, from one control plane, and plugs in through open protocols rather than a proprietary lock-in.

Any model, any framework

Bring your own model and your own agent framework. Governance is applied to the actions, so it does not depend on which model or framework produced them.

Governs any MCP server, changes nothing

Agents connect to their tools through MCP (Model Context Protocol), the open standard. The Agentomy MCP gateway interposes on that path and governs any MCP server: every tool call is checked against your policy before it runs, and a refusal is enforced, not just logged. The server is never patched or forked and never learns it is governed. One config line per agent.

One control plane

Agents spread across frameworks and clouds are governed, monitored, and halted from a single control plane, rather than one silo per stack.

Put your agents under governance today.