Government & defense · Mission authority

Keep autonomous systems within mission authority.

An autonomous system can propose an action without having authority to carry it out. Put a verifiable permission check between that proposal and the vehicle, tool or system it controls. Keep mission limits and restricted actions under human authority—even when a request comes from compromised software.

Download the capabilities statement (PDF)Request a briefing

Start with a rover command the kernel refuses.

The recorded demonstration below shows a rover requesting a thrust adjustment of 9.5 against a permitted limit of 0.5. Inspect the signed decision, then open the live kernel to submit a new request. This demonstrates an execution boundary; it is not evidence of a fielded defense system.

Run the live rover demonstration
Watch one decision

A real refusal, stage by stage.

This is not a mock-up. Every strip below is read from a decision the kernel actually made and signed: a burn command of delta-v 9.5 against grant G1's bound of 0.5.

01 · INTENT

The agent proposes an action

An AI system produces an intent: subject, operation, parameters, target. Nothing has fired yet.

rover-7 · THRUST_ADJUST · Δv 9.5 · G1

02 · BLUEPRINT

The intent is canonicalized

The request is reduced to a deterministic form, so the same intent always evaluates the same way.

intent hash 6d3b2ebce1baa7891fdc4835cb998033…

03 · POLICY

The policy bundle evaluates it

Every rule runs before anything executes. This trace is from the recorded decision, rule by rule.

G-struct ALLOW · G-epoch ALLOW · G-temporal ALLOW · G-catalog REFUSE · G-grant ALLOW · G-bounds REFUSE

04 · AUTHORITY

The grant is checked

Authority is a held grant with bounds. This intent claims grant G1, which authorizes delta-v up to 0.5.

grant G1 · bound Δv ≤ 0.5 · requested 9.5

05 · DECISION

REFUSE

Refused, before execution

Out of bounds, the action never reaches the thruster. This one was nineteen times the authorized maximum.

PARAMETERS_INVALID · EFFECT_BOUND_EXCEEDED

06 · RECEIPT

A signed receipt, either way

The decision, the intent hash, and the rule trace are signed together. Anyone can verify it without trusting ExecLayer.

rcpt-G1-msi6fhqi · ED25519 · 2c9f43e94821c35f5f5a650b…

The receipt this walkthrough prints is the recorded artifact itself. Watch the kernel refuse a live intent.

Interactive exampleRuns in your browser · no real actions

Can an autonomous rover leave its authorized operating area?

Keep vehicle commands inside the mission boundary approved by the responsible human authority.

Choose a request, then check it.

01 · AI asks to act

Unarmed ground rover · controlled evaluation

MISSION COMMAND

Requested movement

Move outside the approved area

02 · Your rule applies

This rover may move only within the approved test area.

03 · Example outcome

Ready to check. No request has been evaluated in this example yet.

Illustrative mission boundary, not a live vehicle control or a defense certification. Position integrity, obstacle avoidance and other safety checks are separate requirements.

See the underlying technology: live rover demo
How it fits into your organization

Who owns it, and how it connects.

You keep your AI and existing systems. We start with one workflow, configure checks around your approved rules, and connect them where the AI tries to act. Authorized requests can proceed. Other requests stop, with a record explaining the decision.

  1. 01 · Set the rules

    Mission authority and program leadership

    Your mission authority and program lead define the approved operating area and actions requiring human authorization, with safety and security review.

  2. 02 · Connect the workflow

    Integration specialists

    Your autonomy and control-system engineers connect the command boundary to trusted mission permissions and vehicle state.

  3. 03 · Check before action

    The connected execution path

    Before a movement command reaches the connected vehicle controller. The integration must prevent the agent from going around the check.

What does a first implementation involve?

We scope one workflow, translate supported rules into a versioned, validated, signed policy package, and connect an adapter that supplies trusted facts such as identity, recipient, and approval status. We then test allowed requests, blocked requests, and attempts to bypass the check before enabling execution.

One maintained kernel can support different policy packages and system adapters. A JSON file alone is not a complete deployment. We confirm rule support and integration requirements for your systems during scoping; additional implementation may be needed.

For a controlled evaluation, test out-of-area commands, revoked permissions, untrusted instructions and loss of required authorization inputs. Agree the fail-closed behavior and human approval boundary with the program before connecting to a vehicle or operational system.

These are typical ownership patterns; responsibilities vary by organization.

Show me how this fits our workflow

Beyond this example

These are possible workflows to scope, each with its own supported rules, trusted inputs, and system integration. The example above does not demonstrate these connections.

Autonomous vehicle commands

Check a proposed movement against the operating area and actions approved for the mission before dispatching it.

Unauthorized or injected commands

Evaluate commands against independently supplied authority, even when an agent or upstream software proposes an out-of-scope action.

Human authorization and evidence

Hold restricted actions until the designated authority approves them, and retain a verifiable decision record for program review.

Mission assurance · Platform capabilities

The control layer for systems that act.

The mission-area example illustrates one authorization rule. The rover receipt separately demonstrates a recorded kernel decision. Deployment requires integration with the program’s command path, trusted state and approved policy; neither example establishes operational readiness.

Runtime authorization

Every AI action is refused unless authorized, decided deterministically before it runs.

Signed evidence

Every decision produces an ED25519-signed receipt tying intent, policy, and outcome together.

Independent verification

Receipts verify in any browser, offline, with no dependence on ExecLayer infrastructure.

Sovereign deployment

Deploys on-prem and air-gapped, with data residency under agency control.

Differentiators
  • Deterministic evaluation: the same request always gets the same decision, which makes the control testable and the evidence reproducible.
  • Enforcement, not observation: policy is applied before the action runs, not reconstructed in audit prep afterwards.
  • Fielded, not conceptual: the same authorization layer governs QueueFlow Sentinel, live on the Amazon Ring Appstore.
  • On the public record: DOI-registered research and multiple provisional patent filings on the enforcement model.
Demonstrated capability & public record
Company data

Legal entity

ExecLayer Inc. (Delaware C-Corp)

Location

Monterey County, CA

UEI

WB5MWC9C4MX9

CAGE

21LT0

SAM.gov

Approved · Active Registration · Expires June 10, 2027

NAICS

511210 · 541511 · 541512 · 541519 · 518210

Point of contact

James D. Benton Jr. · Founder & CEO
james@execlayer.io

Deployment model: on-premises or air-gapped, with data residency under agency control. A live, verifiable demonstration runs in the browser with nothing to install.

Scope a mission-authority evaluation with your program.

Request a briefing