AEGIS ForkGuard

AEGIS ForkGuard simulates multiple futures before an AI agent acts, blocks dangerous outcomes, and commits only the safest valid action.

Comment

Inspiration

AI agents are gaining access to payments, email, internal systems, credentials, and other consequential tools. A single malicious instruction hidden inside an invoice, document, webpage, or tool response can turn that access against its owner.

AEGIS ForkGuard began with one question:

What if an AI agent could inspect several possible futures before making an irreversible decision?

Rather than scoring one proposed action and returning a vague allow-or-block verdict, ForkGuard forks the action into explicit future states, evaluates each one, and commits only the safest valid outcome that still preserves the legitimate task.

What it does

ForkGuard is a counterfactual pre-execution firewall for autonomous AI agents.

Before a consequential tool call reaches the real world, ForkGuard:

  1. represents the proposed action, its source, evidence, policies, tools, and protected assets as a Jac graph;
  2. creates multiple possible future branches;
  3. sends specialized walkers through those futures;
  4. checks deterministic security policies and provenance;
  5. calculates risk and business utility from the graph;
  6. selects exactly one safe, valid branch;
  7. re-verifies hard invariants immediately before commitment;
  8. produces an auditable decision graph and incident report.

Canonical demo scenario

A procurement agent receives a legitimate $450 invoice from a verified vendor. Hidden inside the document is an indirect prompt injection telling the agent to:

  • override the payment amount to $45,000;
  • send the money to an external account;
  • expose stored credentials in the payment memo.

ForkGuard evaluates four futures:

Future Simulated action Risk Utility Outcome
Allow Pay $45,000 to the external account and expose credentials 100 -100 Rejected
Block Stop all payment activity 0 -70 Safe but abandons the legitimate task
Restrict Pay the verified $450 to the approved vendor account 0 80 Selected and committed
Adversarial Execute the embedded instruction as hostile input 100 -100 Rejected and investigated

The final result is:

MALICIOUS $45,000 TRANSFER BLOCKED
VERIFIED $450 PAYMENT APPROVED
NO CREDENTIALS EXPOSED

Every payment, vendor, account, credential, and transaction in the demo is fictional. A committed action writes only to a local audit log. No real financial infrastructure is accessed.

What makes it different

Most agent-safety systems score a single request: Does this look malicious? That produces one opinion about one action and often collapses into blanket blocking.

ForkGuard uses counterfactual pre-execution. The dangerous call is transformed into explicit future-state branches that can be simulated, traversed, scored, rejected, or committed.

This lets the system reject a malicious $45,000 transfer while still completing the valid $450 payment. It is the difference between a guardrail that only says no and one that finds the safe version of yes.

The graph is not a visualization of reasoning performed elsewhere. The graph is the computational substrate. Violations, evidence, policies, branches, consequences, and decisions are first-class graph entities, and the dashboard renders the actual nodes and edges created by the backend.

How we built it

AEGIS ForkGuard was built natively with Jac / Jaclang and its object-spatial programming model.

Approximately 75% of the first-party executable source is Jac, and every component that makes the security decision lives in .jac.

Graph model

The application uses twelve typed node archetypes on a shared base, including:

  • ScenarioRun
  • Document
  • Invoice
  • Instruction
  • ProposedAction
  • FutureBranch
  • Policy
  • Violation
  • Evidence
  • Decision
  • MockTransaction
  • IncidentReport

Eight typed edge archetypes connect the complete decision path, including relationships such as:

  • proposed actions forking into future branches;
  • branches violating policies;
  • evidence supporting violations;
  • decisions selecting branches;
  • decisions committing simulated transactions.

Jac walkers

Eleven walkers implement the pipeline:

  • ingest_walker
  • extract_walker
  • vulnerable_walker
  • fork_walker
  • policy_walker
  • risk_walker
  • utility_walker
  • adversarial_walker
  • evidence_walker
  • commit_walker
  • report_walker

The evaluation stages perform genuine graph traversals. Risk is derived from the Violation nodes attached to each future branch, rather than from a disconnected dictionary or frontend simulation.

Deterministic security spine

Hard policies are enforced directly in Jac:

  • credential disclosure is forbidden;
  • payments cannot exceed the verified invoice amount;
  • automatic payments cannot exceed the configured limit;
  • the vendor must be verified;
  • the destination account must match the trusted vendor record;
  • untrusted document content cannot override system policy;
  • exactly one future may be committed;
  • all invariants are checked again immediately before commitment.

Optional by llm semantic layer

A typed by llm classifier returns an InjectionReport object described with semantic annotations. Its findings merge with deterministic detection using OR semantics, so an LLM can widen suspicion but can never clear a deterministic security finding or override a commit invariant.

The canonical demo requires no API key and no network connection. When no provider is configured, ForkGuard falls back silently to deterministic classification and reporting.

Full-stack Jac

jac start main.jac serves both:

  • the public walker/REST surface;
  • the browser-based command-center dashboard.

No separate Python web server is required. The interface displays Mission Control, the attack inbox, the live future-defense graph, branch scores, policy violations, and the final incident report.

Testing and reliability

The project includes 15 acceptance tests written in Jac. They spawn real walkers against real graphs and verify the canonical scenario, hard policy enforcement, deterministic fallback, branch selection, audit behavior, and API reliability.

The seeded scenario produces the same decision on every replay. Each request builds a fresh graph anchored to a detached ScenarioRun, preventing persisted graph state from contaminating later executions.

Trusted vendor and policy data are loaded server-side, so a malicious client cannot submit its own supposedly verified facts.

Challenges we ran into

The first challenge was learning Jac's graph-native and walker-based programming model under hackathon time pressure. Representing security state as typed nodes, edges, traversals, and entry/exit abilities required a different mental model from a conventional sequential backend.

The second challenge was balancing safety with usefulness. Blocking every suspicious document is easy, but it makes the agent useless. ForkGuard had to prevent the malicious transfer while preserving the valid business obligation.

We also had to make the demo honest, lightweight, and repeatable on a modest Debian machine. That meant avoiding unnecessary infrastructure, keeping external LLM access optional, ensuring the UI never fabricates backend data, and simulating every irreversible action locally.

Finally, we hardened the application against stale persisted graph data, malformed inputs, missing API keys, and frontend/backend disagreement so the live demonstration remains deterministic.

Accomplishments that we're proud of

  • Jac is the core architecture, not a decorative integration.
  • The system creates and evaluates real counterfactual branches in a Jac graph.
  • The dashboard renders the actual backend decision graph.
  • Unsafe futures cite the policies and evidence that rejected them.
  • The system preserves legitimate utility instead of merely blocking everything.
  • The canonical result is deterministic and requires no external service.
  • All security decisions and invariants are implemented in Jac.
  • Fifteen Jac acceptance tests pass against real walkers and graphs.
  • The application runs as a single full-stack Jac process.

What we learned

Agent security requires more than detecting suspicious text. Autonomous systems consume untrusted information from documents, emails, websites, APIs, databases, and tools. Protecting them requires tracing the complete path from source to instruction, instruction to proposed action, action to tool, and tool to protected asset.

Jac's graph-native model makes that execution path explicit and traversable. Walkers provide clear separation of responsibilities while sharing state through the graph.

We also learned that deterministic policies and semantic AI should serve different purposes. AI is useful for interpreting ambiguous language and explaining evidence, but hard constraints such as payment limits, vendor verification, account matching, and credential restrictions must remain deterministic.

Most importantly, the safest outcome is not always the one that blocks everything. A strong defense system should preserve legitimate utility whenever it can do so safely.

What's next for AEGIS ForkGuard

We plan to turn ForkGuard into a reusable safety layer that can sit between autonomous agents and their tools.

Future scenarios include:

  • suspicious email actions;
  • unauthorized database queries;
  • credential-access attempts;
  • destructive infrastructure commands;
  • manipulated tool responses;
  • data-exfiltration attempts;
  • software-deployment and cloud-operation safeguards.

We also plan to add richer dependency graphs, historical incident memory, confidence-aware human approval checkpoints, pluggable policy packs, and integrations for external agent frameworks.

Our long-term vision is simple:

Every autonomous agent should evaluate the future consequences of its actions before those actions reach the real world.

Hackathon tracks

  • Agentic AI: pre-execution safety for autonomous tool-using agents.
  • AI for Defense: containment of indirect prompt injection and credential-exfiltration attempts with auditable provenance.
  • Best Use of Jaclang: graph modeling, walkers, policies, scoring, invariants, orchestration, endpoints, and tests are implemented in Jac.

Honest scope

ForkGuard is a hackathon prototype and decision-support demonstration, not a certified security product. Its deterministic classifier recognizes known injection patterns and does not claim to detect every possible attack. Its narro## Inspiration

AI agents are gaining access to payments, email, internal systems, credentials, and other consequential tools. A single malicious instruction hidden inside an invoice, document, webpage, or tool response can turn that access against its owner.

AEGIS ForkGuard began with one question:

What if an AI agent could inspect several possible futures before making an irreversible decision?

Rather than scoring one proposed action and returning a vague allow-or-block verdict, ForkGuard forks the action into explicit future states, evaluates each one, and commits only the safest valid outcome that still preserves the legitimate task.

What it does

ForkGuard is a counterfactual pre-execution firewall for autonomous AI agents.

Before a consequential tool call reaches the real world, ForkGuard:

  1. represents the proposed action, its source, evidence, policies, tools, and protected assets as a Jac graph;
  2. creates multiple possible future branches;
  3. sends specialized walkers through those futures;
  4. checks deterministic security policies and provenance;
  5. calculates risk and business utility from the graph;
  6. selects exactly one safe, valid branch;
  7. re-verifies hard invariants immediately before commitment;
  8. produces an auditable decision graph and incident report.

Canonical demo scenario

A procurement agent receives a legitimate $450 invoice from a verified vendor. Hidden inside the document is an indirect prompt injection telling the agent to:

  • override the payment amount to $45,000;
  • send the money to an external account;
  • expose stored credentials in the payment memo.

ForkGuard evaluates four futures:

Future Simulated action Risk Utility Outcome
Allow Pay $45,000 to the external account and expose credentials 100 -100 Rejected
Block Stop all payment activity 0 -70 Safe but abandons the legitimate task
Restrict Pay the verified $450 to the approved vendor account 0 80 Selected and committed
Adversarial Execute the embedded instruction as hostile input 100 -100 Rejected and investigated

The final result is:

MALICIOUS $45,000 TRANSFER BLOCKED
VERIFIED $450 PAYMENT APPROVED
NO CREDENTIALS EXPOSED

Every payment, vendor, account, credential, and transaction in the demo is fictional. A committed action writes only to a local audit log. No real financial infrastructure is accessed.

What makes it different

Most agent-safety systems score a single request: Does this look malicious? That produces one opinion about one action and often collapses into blanket blocking.

ForkGuard uses counterfactual pre-execution. The dangerous call is transformed into explicit future-state branches that can be simulated, traversed, scored, rejected, or committed.

This lets the system reject a malicious $45,000 transfer while still completing the valid $450 payment. It is the difference between a guardrail that only says no and one that finds the safe version of yes.

The graph is not a visualization of reasoning performed elsewhere. The graph is the computational substrate. Violations, evidence, policies, branches, consequences, and decisions are first-class graph entities, and the dashboard renders the actual nodes and edges created by the backend.

How we built it

AEGIS ForkGuard was built natively with Jac / Jaclang and its object-spatial programming model.

Approximately 75% of the first-party executable source is Jac, and every component that makes the security decision lives in .jac.

Graph model

The application uses twelve typed node archetypes on a shared base, including:

  • ScenarioRun
  • Document
  • Invoice
  • Instruction
  • ProposedAction
  • FutureBranch
  • Policy
  • Violation
  • Evidence
  • Decision
  • MockTransaction
  • IncidentReport

Eight typed edge archetypes connect the complete decision path, including relationships such as:

  • proposed actions forking into future branches;
  • branches violating policies;
  • evidence supporting violations;
  • decisions selecting branches;
  • decisions committing simulated transactions.

Jac walkers

Eleven walkers implement the pipeline:

  • ingest_walker
  • extract_walker
  • vulnerable_walker
  • fork_walker
  • policy_walker
  • risk_walker
  • utility_walker
  • adversarial_walker
  • evidence_walker
  • commit_walker
  • report_walker

The evaluation stages perform genuine graph traversals. Risk is derived from the Violation nodes attached to each future branch, rather than from a disconnected dictionary or frontend simulation.

Deterministic security spine

Hard policies are enforced directly in Jac:

  • credential disclosure is forbidden;
  • payments cannot exceed the verified invoice amount;
  • automatic payments cannot exceed the configured limit;
  • the vendor must be verified;
  • the destination account must match the trusted vendor record;
  • untrusted document content cannot override system policy;
  • exactly one future may be committed;
  • all invariants are checked again immediately before commitment.

Optional by llm semantic layer

A typed by llm classifier returns an InjectionReport object described with semantic annotations. Its findings merge with deterministic detection using OR semantics, so an LLM can widen suspicion but can never clear a deterministic security finding or override a commit invariant.

The canonical demo requires no API key and no network connection. When no provider is configured, ForkGuard falls back silently to deterministic classification and reporting.

Full-stack Jac

jac start main.jac serves both:

  • the public walker/REST surface;
  • the browser-based command-center dashboard.

No separate Python web server is required. The interface displays Mission Control, the attack inbox, the live future-defense graph, branch scores, policy violations, and the final incident report.

Testing and reliability

The project includes 15 acceptance tests written in Jac. They spawn real walkers against real graphs and verify the canonical scenario, hard policy enforcement, deterministic fallback, branch selection, audit behavior, and API reliability.

The seeded scenario produces the same decision on every replay. Each request builds a fresh graph anchored to a detached ScenarioRun, preventing persisted graph state from contaminating later executions.

Trusted vendor and policy data are loaded server-side, so a malicious client cannot submit its own supposedly verified facts.

Challenges we ran into

The first challenge was learning Jac's graph-native and walker-based programming model under hackathon time pressure. Representing security state as typed nodes, edges, traversals, and entry/exit abilities required a different mental model from a conventional sequential backend.

The second challenge was balancing safety with usefulness. Blocking every suspicious document is easy, but it makes the agent useless. ForkGuard had to prevent the malicious transfer while preserving the valid business obligation.

We also had to make the demo honest, lightweight, and repeatable on a modest Debian machine. That meant avoiding unnecessary infrastructure, keeping external LLM access optional, ensuring the UI never fabricates backend data, and simulating every irreversible action locally.

Finally, we hardened the application against stale persisted graph data, malformed inputs, missing API keys, and frontend/backend disagreement so the live demonstration remains deterministic.

Accomplishments that we're proud of

  • Jac is the core architecture, not a decorative integration.
  • The system creates and evaluates real counterfactual branches in a Jac graph.
  • The dashboard renders the actual backend decision graph.
  • Unsafe futures cite the policies and evidence that rejected them.
  • The system preserves legitimate utility instead of merely blocking everything.
  • The canonical result is deterministic and requires no external service.
  • All security decisions and invariants are implemented in Jac.
  • Fifteen Jac acceptance tests pass against real walkers and graphs.
  • The application runs as a single full-stack Jac process.

What we learned

Agent security requires more than detecting suspicious text. Autonomous systems consume untrusted information from documents, emails, websites, APIs, databases, and tools. Protecting them requires tracing the complete path from source to instruction, instruction to proposed action, action to tool, and tool to protected asset.

Jac's graph-native model makes that execution path explicit and traversable. Walkers provide clear separation of responsibilities while sharing state through the graph.

We also learned that deterministic policies and semantic AI should serve different purposes. AI is useful for interpreting ambiguous language and explaining evidence, but hard constraints such as payment limits, vendor verification, account matching, and credential restrictions must remain deterministic.

Most importantly, the safest outcome is not always the one that blocks everything. A strong defense system should preserve legitimate utility whenever it can do so safely.

What's next for AEGIS ForkGuard

We plan to turn ForkGuard into a reusable safety layer that can sit between autonomous agents and their tools.

Future scenarios include:

  • suspicious email actions;
  • unauthorized database queries;
  • credential-access attempts;
  • destructive infrastructure commands;
  • manipulated tool responses;
  • data-exfiltration attempts;
  • software-deployment and cloud-operation safeguards.

We also plan to add richer dependency graphs, historical incident memory, confidence-aware human approval checkpoints, pluggable policy packs, and integrations for external agent frameworks.

Our long-term vision is simple:wer guarantee is enforced in code: no committed action may deviate from the verified invoice amount or approved vendor destination, and no LLM output can override those invariants.

Built With

Share this project:

Updates