IVYX vs agent policy gateways
Agent policy gateways and IVYX Studio agree on the guarantee that matters: a rule is evaluated before a tool call runs, and a refusal is recorded. The comparison worth making is what each rule can see, whom it governs, and what the record holds afterwards.
The short answer
- Use a policy gateway when the tools your agent reaches live outside IVYX. Amazon Bedrock AgentCore Policy sits at the AgentCore Gateway in AWS; AgentFence runs as a local MCP proxy in front of any MCP server.
- Use IVYX Studio when the work is inside the workspace, the rule has to understand what a capability does rather than what it is called, and the person at the keyboard has to meet the same rule as the agent.
- The two combine. IVYX exports its policy to gateway formats, so the rules rehearsed on a laptop are the ones enforced in production.
| Criterion | Amazon Bedrock AgentCore Policy | AgentFence | IVYX Studio |
|---|---|---|---|
| Where the rule runs | At the AgentCore Gateway, in AWS | On your machine, as an MCP proxy | On your machine, inside the workspace, and headless in CI |
| What it sits in front of | Tools registered with the gateway | Any MCP server | Every capability in the workspace, and calls arriving over MCP |
| Policy language | Cedar | YAML rules, first match wins | A policy file kept with the project, with conditions on the arguments of a call |
| Default | Deny | Deny | Deny |
| What the rule can see | The tool call and its inputs | The tool name and its arguments, including paths, URLs and shell commands | The capability manifest: an action from a closed vocabulary of fourteen, a risk level, whether a person is needed, and the argument tuple |
| Who it governs | Agents calling through the gateway | Agents calling through the proxy | Agents and people alike. A UI action and an MCP call enter the same gateway and meet the same rule |
| Approval step | Not described in the material we checked | A call can be routed to approval | Declared in the manifest, and the grant is bound to the arguments you were shown |
| Record | Not described in the material we checked | Append-only JSONL log, optionally signed with Ed25519 | One signed evidence package per run: the datasets and files touched, figures with their bounds, every decision, every approval |
| Cost and licence | AWS service pricing | Apache 2.0, free | 7-day trial, then a licence key |
Where the gateways are ahead
Reach and price. AgentCore Policy governs any tool a team registers with the gateway, is backed by AWS, and uses Cedar, a policy language with formally analysable semantics that other tools are adopting too. AgentFence is free, open source, and works in front of any MCP server on the machine. IVYX no longer asks you to keep a window open to be governed, because ivyx serve --stdio puts the same gate in front of an MCP client from a terminal. The tools it governs are still the ones inside the workspace. If your agent's tools live outside IVYX, one of these is the right layer and IVYX does not compete for that position.
Where the line falls
A proxy governs tools it does not own, so the most a rule can see is a name and the arguments that arrived with it. IVYX owns both sides of the call: every capability declares in a manifest which action it performs from a closed vocabulary of fourteen, what risk it carries and whether it needs a person, and the rule is evaluated against that declaration. That is the difference between “deny calls to a tool named promote with alias production” and “deny any high-risk promotion to production, whoever calls it”. The second rule also covers the person at the keyboard, which no proxy in front of an agent does, and an agent additionally passes an agent-mode profile, so an agent is never gated less than a person. And when the run ends, a proxy holds a list of calls; IVYX holds the datasets those calls read, the figures they produced with the bounds they were measured against, and the approval that let the model through.
Frequently asked
What is the difference between an MCP policy proxy and IVYX?
An MCP policy proxy sits between an agent and an MCP server and decides each call from the tool name and its arguments; AgentFence is an example that runs locally, and Amazon Bedrock AgentCore Policy performs the same role at the AgentCore Gateway. IVYX Studio evaluates its rule inside the workspace against a capability manifest, so the rule reads an action class and a risk level rather than a string, applies to a person using the app as well as to an agent, and records the decision in an evidence package that also holds the data and figures of the run.
Can I use AgentFence or AgentCore Policy together with IVYX Studio?
AgentFence or AgentCore Policy can run alongside IVYX Studio. A proxy governs the tools outside the workspace, IVYX governs the capabilities inside it, and IVYX exports its policy to gateway formats so the rules rehearsed on a laptop are the ones enforced in production.
Does IVYX Studio use Cedar?
IVYX Studio keeps its policy in a project policy file with conditions on the arguments of a call, and exports it to the formats a gateway needs. The two gateways supported today are Obot and Arcade, alongside a neutral bundle that a fourth target is written against. Cedar is not a supported export at the time of writing, so if Cedar is on your gateway, treat that as a gap to check with us before you commit.
Competitor rows are drawn from each vendor's published material and were checked on 6 September 2026. A comparison page with a stale competitor row does more damage than no page at all, so if you are reading this much later, treat the competitor columns as dated.
Runs on your machine. macOS and Linux.