Aegis #

Aegis is IDv4’s first product - a runtime control plane for AI agents. It helps regulated institutions deploy agents across sensitive systems by making identity, policy, approval, and audit explicit enough for builders to move fast and control teams to still say yes.

It is the first concrete step in IDv4’s mission to build an identity plane for the agent era. Software acting on a user’s behalf is not the new part - OAuth solved delegated access long ago. Every prior epoch of identity could assume the actor was either a person or deterministic software whose behavior was fixed by its code. An AI agent is neither: it is nondeterministic, it improvises, and it exercises judgment more like a person than like the predictable software our controls were built for - yet it is not a person, and no human reviews each action it takes. That is the open problem of this epoch, and where Aegis starts.

The problem it solves #

Enterprises are putting agents into production faster than they can govern them. A compliance team’s only safe answer becomes “no,” because they cannot see what agents are doing, cannot scope what those agents are allowed to do, and cannot prove after the fact what happened. Security becomes the bottleneck, and innovation stalls against it.

The deeper issue is architectural. Traditional access controls assume a human is present at the point of action. Agents act continuously, at machine speed, on delegated authority - so the controls have to move to where the agent actually operates: the calls it makes to models, tools, and other agents.

How it works #

Aegis sits in the path of agent traffic as a set of gateways. Every call an agent makes - to an LLM, to a tool over MCP, to another agent - passes through a single enforcement point that does four things in one pass:

Identity - gives the agent a verifiable identity bound to the organization, the agent itself, the task it is doing, and, when it acts for a person, that user.
Policy - evaluates the call against rules written in Cedar, the same authorization language AWS uses - rules that are human-readable and designed to be analyzable, not opaque ML scores.
Approval - pauses a consequential action for a human to approve, without the agent needing any special code to support it.
Audit - records the decision in a tamper-evident, hash-chained log, attributed to the full identity chain.

Because enforcement lives at the gateway, the agent never holds the credentials for the systems it reaches, and the record of what it did is observed at the boundary rather than self-reported.

A worked example #

The following is a synthetic walkthrough used to show the mechanism - not a customer deployment.

A compliance officer registers a new finance agent and writes a short Cedar policy: forbid any agent from touching resources tagged PII. It is live before the agent runs once.

The developer points the agent at the Aegis gateway instead of the raw API. Its first calls - read an invoice, summarize it with an approved model - succeed. Then the agent tries a tool that reads customer records. Instead of a generic “access denied,” it gets back a structured error that names the exact policy that blocked it.

The compliance officer opens the audit log and sees that denial recorded immutably, attributed to the full chain: which organization, which agent, on whose behalf, for which task.

One request substantiates four things at once: an unauthorized action was prevented, not merely logged; the developer got an unblocking, specific answer instead of a two-week ticket; the policy is readable and provable; and there is an unbroken chain of custody from human intent to machine action.

What each team gets #

The same path through the gateway serves a different need for each person it touches:

Security and compliance get a single place to see every agent, rules written in readable Cedar with a simulator that shows exactly what a rule will decide before it goes live, and an immutable record of every decision - a scalpel instead of a blanket “no.”
Developers get one gateway endpoint and self-service credentials, and when a call is blocked, a specific error that names the exact policy that blocked it - not a generic “access denied” - so they fix it themselves instead of waiting on a security ticket.
Operations get a live view of the agent fleet, one queue for the actions that need a human to sign off - with automatic warnings before an approval goes stale - and a complete, gateway-built timeline to reconstruct any task in minutes rather than hours.
End users get a portal to see what agents are doing in their name, approve the consequential actions with real context - what is being done and why, not just a dollar amount - and connect or disconnect the services their agents may use.
The business gets a way to bound the blast radius of autonomous agents and adopt them on a clear, governed path, instead of letting security be the brake on AI.

Why it is different #

Most of the first wave of agent security is observability - tools that map your agents and tell you what they did. That is necessary, but it reports after the fact. Aegis is built to prevent the action that shouldn’t happen, at the moment it is attempted. The design choices that follow from that:

Enforcement, not just observation - a decision is made before the call is forwarded, not an alert raised after.
A layered identity for agents - organization, agent, task, and user as one chain, so a single task can be paused for review without halting the whole fleet.
Policy you can reason about - Cedar is inspectable and deterministic; a formal policy analyzer (“can agent X ever reach resource Y?”) is on the roadmap.
Enforcement inside the protocols agents actually use - tool names and methods over MCP become first-class policy inputs, so authorization is fine-grained rather than all-or-nothing.
A call graph you did not have to instrument - the task tree is assembled at the gateway, so it is not something an agent can forget or fake.

How you adopt it #

Aegis is designed to grow with a team rather than demand a big-bang migration. The enforcement point sits in the path of agent traffic from day one - even in audit-only mode - so adding control later means switching on policy, not retrofitting enforcement onto a system that was only watching. A team can start with an OpenAI-compatible proxy and audit logging, then add Cedar policy, then content inspection for things like PII and prompt injection, then human-in-the-loop approvals and multi-team governance - each step independently useful. It is designed to be self-hostable, so it can run inside your own environment.

Where it stands #

Aegis is early. We are opening a design-partner program for regulated industries - banking, healthcare, insurance - aimed at teams putting agents into production now that need the controls to match. If that is you, we want to talk.

→ idv4.ai - product, live demo, and the design partner program.