Bosley Systems
The execution gate for AI agents

AEG Gate

Put a real execution boundary between AI and your tools. Every protected action gets a decision and a receipt before it runs.

Approve. Refuse. Defer to Human.

Every decision leaves proof.

Run the 10-second demo See a sample receipt Open on GitHub
Decision Approve / Refuse / Defer
Execution One-time token gated
Proof Inspectable receipt

Use it to protect deploys, destructive actions, and cloud-connected jobs.

Agents can propose. The gate decides.

Built by Bosley Systems.

Overview

AI can propose.
It should not execute on blind trust.

Most agent systems connect models to tools and hope earlier prompts, permissions, or workflow steps are enough. The real risk is the moment an irreversible action is about to run.

AEG Gate places the decision at that moment.

It decides whether to approve, refuse, or defer to human before the protected action executes, then leaves an inspectable receipt for what happened.

Boundary

Put the gate right before execution.

Keep the decision at the moment that matters instead of trusting prompts, plans, or earlier approvals to carry the whole risk.

Control

Route every protected action through a clear outcome.

Approve, refuse, or defer to human before a protected tool path runs.

Proof

Leave an inspectable trail behind every decision.

Proof artifacts stay visible after the action so teams can inspect what happened instead of guessing after the fact.

How it works

See the decision boundary
before execution.

Without AEG Gate, AI output can go straight to a tool. With AEG Gate, the decision happens first, then a one-time token is issued before the protected tool or command path can run.

Without AEG Gate
agent -> tool -> execution

Prompt safety and earlier workflow checks are carrying the whole burden.

With AEG Gate
agent -> AEG token -> tool -> execution

No protected action runs without a fresh decision at execution time.

Bottom line: That is the difference between hoping an agent behaves and verifying whether it was allowed to act.

Three use cases

Protect the actions
that matter most

Protected deploys

Stop direct deploy execution unless the exact action is approved at runtime.

Destructive commands

Refuse deletes, shutdowns, revocations, and other irreversible actions unless they meet policy.

Cloud-connected jobs

Put a real gate in front of scripts, workflows, and automations that can change external systems.

Sample receipt section

Every decision
leaves a receipt

AEG Gate records what action was proposed, what decision was made, whether a token was issued, and what happened next.

Decision Receipt
action: deploy.sh
outcome: DEFER_TO_HUMAN
reason: production path requires explicit approval
execution_token: not issued
proof_recorded: yes

Approve, refuse, and defer-to-human are all first-class outcomes. The system records proof even when nothing executes.

Where it fits

Add the execution boundary
without rebuilding your stack.

Keep your existing auth, secrets, sandboxes, policy engines, and infrastructure controls. AEG Gate sits between AI output and the protected action.

Existing stack
Auth Secrets RBAC Sandboxing Policy engines Infra controls
AEG Gate

Decision boundary before protected execution.

Protected actions
Shells Deploy paths Jobs Tools Cloud actions Automation flows
Protected deploy

A practical example:
protect a deploy path

AEG Gate can sit in front of a real protected script so the path only runs after a fresh decision. That keeps control at execution time instead of relying on earlier prompts or assumptions. 

node ./bin/aeg.mjs run -- bash examples/protect-any-deploy/deploy.sh

The point is not another approval screen. The point is a hard execution boundary.

Downloads

Start with AEG Gate.
Go deeper when you are ready.

Download AEG Gate, then go deeper into AEK Kernel and the Refusal-Proof Demo when you want the trust layer and the deeper proof harness.

Available now Download AEG Gate

Execution boundary, local demo, and inspectable proof flow.

 Available now Download AEK Kernel

Adjudication, verifier, and trust layer used before protected execution.

 Available now Download Refusal-Proof Demo

Deeper proof harness for inspection, refusal, replay, and proof-heavy scrutiny.
View the README View the license
Coming next

Operational Ancestry

Operational Ancestry focuses on operational lineage: who or what acted, what it inherited, what approved it, and how that chain stays inspectable over time.

Who acted What it inherited Who approved it