Cerberus

Agents now run datacenter fabrics, but authorization is broken: full access risks outages, human approval kills autonomy. Cerberus gives each agent a scoped, revocable AI Passport, checked at the gate

Comment

Inspiration

Autonomous agents are starting to act on real infrastructure. They provision fabrics, drain racks, and push switch configuration. That is genuinely useful, but it creates a hard problem: how do you let an agent act without either handing it broad standing credentials or forcing a human to approve every step?

Picture Maya, a network engineer on call for a GPU cluster. She wants an agent to remove routine operational toil, but she is still the person whose pager goes off if the automation gets production wrong. Give the agent broad credentials and one wrong inference can affect an entire fabric. Put Maya in the loop for every action and much of the value of autonomy disappears.

While experimenting with a natural-language provisioning planner and an sFlow telemetry server exposed to agents over MCP, one question kept surfacing: for irreversible actions, should an agent execute directly, or should something deterministic sit between AI intent and production?

Egoist's AI Passport reframed the problem for us.

AI Passport already gives people control over what context an AI app may access about them. Cerberus explores the next question: can that same user-owned context help govern what an autonomous agent may do on their behalf?

That is Cerberus.

What it does

Cerberus uses AI Passport as the human-owned context and delegation layer between a person and the autonomous agents acting for them.

Maya owns her AI Passport. Inside it, she can maintain an Operational Delegation context containing preferences and constraints such as:

  • which agent she trusts for maintenance tasks
  • which classes of actions she is willing to delegate
  • her approved maintenance window
  • her preferred maximum lease duration
  • when the agent should stop and escalate to her

The Cerberus agent does not automatically receive that context. It requests an AI Passport Pass for only the categories it needs. Maya controls that access and can revoke it at any time.

Suppose Maya has approved the following context:

My maintenance agent may drain racks during my approved maintenance window, for no more than 30 minutes per operation.

The agent later proposes draining rack 4.

AI Passport gives Cerberus scoped access to Maya's relevant delegation context. The agent then presents its proposed action to a deterministic gate called the Portcullis.

Portcullis derives what the agent may actually do by combining:

$$\text{Effective Authority} = \text{Request} \cap \text{Delegation} \cap \text{Entitlement} \cap \text{Agent Policy}$$

Where:

  • Request = what the agent is trying to do
  • Delegation = what Maya has chosen to allow
  • Entitlement = what Maya is currently authorized to do
  • Agent Policy = what the enterprise permits autonomous agents to do

This distinction is fundamental.

The enterprise decides what Maya is authorized to do.

Maya decides what subset of that authority she is comfortable allowing an agent to exercise on her behalf.

The enterprise also decides which privileges may be delegated to autonomous agents at all.

For example, Maya might personally have permission to modify spine switches while enterprise policy still prohibits autonomous agents from doing so.

The enterprise keeps security sovereignty. Maya keeps delegation sovereignty.

AI Passport provides the user-controlled context. Portcullis combines that context with enterprise authority, policy, and live operational state to make a production authorization decision.

How we built it

Cerberus is organized around one principle:

Probabilistic AI may propose actions, but irreversible execution must cross a deterministic gate.

The system has five logical layers:

  • Intent: a planner agent turns "drain rack 4" into a structured change plan.
  • Passport Context: Cerberus requests scoped access to Maya's Operational Delegation context through AI Passport.
  • Authorization: Portcullis combines that user-controlled context with current IAM entitlement, enterprise agent policy, and safety state.
  • Control: an orchestrator converts an approved plan into validated switch configuration.
  • Observability: telemetry and authoritative controller or scheduler state are checked before execution.

For the ideathon, we built a working logical-path browser prototype using mock IAM, a mock scheduler, and a mock orchestrator. This lets us demonstrate the complete authorization flow without touching production infrastructure.

The demo follows one simple sequence:

Maya approves Operational Delegation context
→ Cerberus requests scoped AI Passport access
→ Maya grants the Pass
→ AI Passport records the context access
→ Agent proposes rack.drain
→ Portcullis evaluates user context + current IAM + agent policy + live state
→ DENY while the rack is unsafe
→ Conditions become safe
→ Agent retries
→ PASS
→ Portcullis records the execution decision
→ Maya revokes Cerberus's context access
→ Next attempt: DENY

The infrastructure implementation is also grounded in technologies we have already explored, including SONiC-based network orchestration and an sFlow telemetry server exposed to agents through MCP.

Two kinds of receipts

Cerberus keeps the responsibilities of AI Passport and enterprise authorization separate.

AI Passport receipt

Shows Maya that Cerberus accessed a specific category of her context, such as Operational Delegation, and when that access occurred.

Cerberus execution receipt

Records the production authorization decision, including the action requested, policy version, decision, and cryptographic references to the evaluated state.

This lets Maya see both:

  1. what the agent accessed about her
  2. what the agent attempted to do with that context

Sensitive enterprise identifiers and raw telemetry remain inside the enterprise boundary. AI Passport only needs the minimum user-controlled context required by the application.

Challenges we ran into

The hardest part was not building the demo. It was separating the different kinds of authority correctly.

Authority vs. delegation

The enterprise determines what Maya is allowed to do.

Maya determines what she is comfortable allowing an agent to do on her behalf.

Those are different decisions, and Cerberus preserves both.

Context vs. execution authority

AI Passport should not become another enterprise IAM system.

Its role is to hold Maya's user-controlled context and let her decide which applications may access it.

Portcullis remains responsible for turning that context into an execution decision using current enterprise authorization, policy, and operational state.

Human control without human approval on every action

Requiring Maya to click "approve" before every rack operation would recreate the human-in-the-loop bottleneck.

Instead, Maya defines and approves her standing delegation context once, then separately grants Cerberus scoped access to that context through AI Passport.

She can later change the context or revoke Cerberus's access. Inside that user-approved boundary, the agent can operate without repeatedly interrupting her for every action.

Privacy boundaries

Operational context can itself be sensitive. Resource identifiers, topology, entitlements, and telemetry should not be copied into a personal context service unnecessarily.

We therefore keep enterprise-specific details inside the enterprise boundary and use opaque references when information must cross boundaries.

Fresh authority

A credential, permission, or policy decision can become stale.

Portcullis evaluates current enterprise entitlement, current agent-delegation policy, current AI Passport context-access status, and authoritative operational state when execution is attempted.

If any required information cannot be verified, the action fails closed.

Accomplishments that we're proud of

  • We found a way to use AI Passport's existing primitives, including user-owned context, scoped Passes, revocation, receipts, and approval, in a new autonomous-agent setting.
  • We separated personal delegation context from enterprise execution authority rather than trying to replace IAM.
  • We built a deterministic authorization boundary around a probabilistic agent.
  • We created a prototype that demonstrates the complete story in about 90 seconds: DENY, state change, PASS, receipt, revoke, DENY.
  • We designed the model to complement technologies such as OAuth, SPIFFE, OPA, mTLS, and enterprise IAM rather than inventing new cryptography.

What we learned

The deepest lesson was that the interesting primitive is governance, not cryptography.

Existing identity infrastructure is already good at answering:

What is this employee authorized to do?

AI Passport introduces a different question:

What does this person want an AI application or agent to know about them?

Cerberus connects that idea to autonomous action:

Of everything I am authorized to do, what am I comfortable allowing this agent to do for me?

The answer should not live permanently and independently inside every AI agent.

It belongs in context the person can inspect, change, share selectively, and revoke.

We also learned that enterprise-grade authorization requires more than a signed credential. Current-state evaluation, fail-closed defaults, explicit enterprise policy, revocation, and clean data boundaries are what separate a convincing demo from something a platform team could eventually trust.

How AI Passport's Inbox fits

Delegation context should also evolve under the user's control.

Suppose Cerberus notices that Maya consistently reduces maintenance leases from 30 minutes to 15 minutes.

The agent should not silently modify her Passport.

Instead, it can propose:

Suggested update: Preferred maximum maintenance lease = 15 minutes.

That proposal lands in the AI Passport Inbox.

Maya chooses whether to approve or reject it.

This preserves the core AI Passport principle:

AI can learn from the user, but the user decides what becomes part of their persistent context.

What's next for Cerberus

The next step is to replace the prototype adapters with real enterprise integrations:

  • a real IAM attestation source
  • an enterprise agent-delegation policy engine
  • authoritative scheduler state
  • production telemetry
  • an orchestrator connection protected by mTLS
  • an enforced Portcullis-only execution path

After infrastructure, the same pattern can extend to deployment agents, database agents, financial agents, and other systems where AI takes consequential actions.

Infrastructure is a useful proving ground because mistakes have immediate, measurable consequences. But the broader idea is larger:

AI Passport can provide the user-controlled context that tells autonomous systems our preferences and boundaries. Cerberus shows how that context can be combined with enterprise authority, policy, and live state before an agent is allowed to act.

Today AI Passport controls what an AI may know about you. Cerberus explores how that same user-owned context can help control what an AI may do for you.

Built With

Share this project:

Updates

Submission history