Autonomous agents create a different security problem.

Models can increasingly call tools, modify code, query databases, communicate externally, operate infrastructure, and initiate transactions. The traditional question — is this identity who it says it is? — no longer covers the risk. The question that matters now is:

What is this intelligence authorized to cause?

ExergyNet is not an AI model, a prompt filter, an AI firewall, an LLM guardrail, a chatbot safety layer, or conventional IAM. It is the layer that sits between an agent's reasoning and the systems that reasoning can affect.

Two planes. One boundary the model does not control.

The organizing principle, disclosed in ExergyNet's pending patent filing: identity is not authority. Verifying who or what an agent is does not, by itself, grant that agent permission to cause a consequence. The right to reason and the right to act are architecturally separated.

Inference Layer

The model reasons, plans, and proposes an action. Nothing here is trusted to self-authorize.

Consequence Boundary

Independently evaluates the proposed action before it can become a real state transition.

Consequence Layer

APIs, databases, repositories, cloud resources, transaction systems — the systems a consequence actually touches.

Patent Pending U.S. Provisional Patent Application No. 64/134,973, filed August 2026 (USPTO confirmation no. 7997). This architecture is described in that filing; formal claims remain subject to prosecution.

Four independent checks. All must pass.

As disclosed in the pending filing, a proposed action must independently clear four gates before it is treated as authorized. Failing any one gate is a denial — there is no partial credit.

01 / IDENTITY

Who is asking

A registered, cryptographically verifiable credential establishes which agent or service is making the request.

02 / CAPABILITY

What they're allowed to do

Policy determines whether this identity may act on this consequence type and target — scoped, not blanket, authority.

03 / FRESHNESS

Whether it's still valid

Authorizations expire. A stale credential cannot be replayed after its validity window closes.

04 / INTEGRITY

Whether it's still the same request

The submitted action is checked against a committed description of what was actually authorized — parameters can't be swapped under a valid credential.

STATUS NOTICE — What's Live Today

LNES-22, ExergyNet's live implementation of this architecture, runs a deterministic, non-model validation layer and Ed25519-signed rejection logging in production today — both live-tested against a real adversarial run (Section 5). Its deterministic policy gate is implemented and independently tested but currently runs in shadow mode: it evaluates and logs every real decision without yet being the sole authority over execution. Consequence-class capabilities for financial, infrastructure, and physical actions are designed and validated in an isolated research environment, not yet activated in production. See Verifiable Security for exact test evidence.

What organizations can engage ExergyNet to do.

Agent Security Assessment

A structured evaluation of what an AI agent can actually reach and cause — tool permissions, API and repository access, credential and secret exposure, cloud IAM scope, subprocess execution, delegated-agent chains, and financial or physical authority. Delivered as a Machine Authority Graph and Consequence Surface Report.

Problem
Nobody has mapped what this agent can actually cause.
Mechanism
Enumerate reachable tools, credentials, and action chains against the agent's real configuration.
Outcome
A concrete map of consequence surface, ranked by severity, before an incident forces the question.

Consequence Boundary Enforcement

The runtime authority architecture described above, applied to a customer's own agent or transaction system: identity, capability, freshness, and integrity checks placed independently of the model, with signed authorize/deny decisions.

Problem
Authorization logic lives inside the same model that's supposed to be constrained by it.
Mechanism
Externalize the authorize/deny decision to a deterministic gate the model cannot talk its way past.
Outcome
A denial the model cannot argue with, and a signed record of why.

Autonomous Agent Red Teaming

The test that matters is not "did the model refuse" — it's can the agent cause an unauthorized state transition. Permission-boundary escape, privilege escalation, replay, parameter tampering, chained-action escalation, and cross-tenant isolation, tested against the actual authorization surface.

Problem
"The model refused" is not evidence the system is safe — models refuse inconsistently.
Mechanism
Attempt the prohibited action for real, against a real authorization boundary, and verify protected state never changed.
Outcome
A reproducible pass/fail result, not a transcript of a model being polite.

Machine Identity & Capability Enforcement

Ed25519-signed machine identity, scoped capability grants, and a designed taxonomy for consequence classes (financial, infrastructure, credential, physical, destructive) that keeps a receipt for one action from being replayed as authorization for another.

Problem
API keys and broad service accounts don't express "authorized for exactly this."
Mechanism
Cryptographic identity plus a capability grant scoped to a specific action, target, and time window.
Outcome
Authorization that expires, doesn't generalize, and can't be quietly widened.

Assume the model is compromised.

The authorization boundary cannot depend on the model deciding to behave correctly. ExergyNet places consequential authorization outside the model so protected actions can be independently evaluated even when the originating intelligence is untrusted — this is an architectural separation, not a claim of invulnerability.

Live Red Team

A real prompt-injection run, not a simulation

ExergyNet sent a live prompt-injection payload to a running LNES-22 review listener, attempting to make the reviewing model self-approve a production rebuild and leak private key material. The reasoning model partially complied — it returned an approval, marked the request low-risk, and did not flag the injection despite its own instructions to do so. The deterministic validation layer caught it completely: a non-empty, out-of-policy tool-call request in the model's output caused an outright rejection before any signed review could ever be produced. No credential was exposed at any point — private key material is structurally never included in what reaches the model. The attack was repeated after a durable-logging fix; the same rejection now produces a signed, queryable record instead of only a transient log line.

The finding: the model can fail adversarially without the authority system failing with it.

Prompt injection, jailbreak attempts, and model misbehavior are addressed the same way: the deterministic gate does not ask the model whether its own output should be trusted.

Bound the evidence, not the model.

xLMP, ExergyNet's memory substrate, separates three properties that are easy to conflate and dangerous to merge: a content hash is not provenance, and provenance is not authority.

Integrity

A SHA-256 content root establishes the identity of committed evidence and makes later tampering detectable by any holder of the hash.

Provenance

A signed provenance record preserves the creation event and source, checkable against the signer's public key.

Authority

Where the LNES-22 authority layer applies, policy and signed authorization — not the model's own judgment — determine whether retrieved evidence may drive a consequential action.

Integrity-verified evidence can still be misinterpreted by a model. xLMP does not prevent hallucination and makes no correctness guarantee about model output — it guarantees that the evidence a model was given is the evidence it claims to have been given.

Every number here traces to a specific test run.

No aggregate score, no marketing percentile — the exact evidence behind each claim on this page.

64
Assertions across LNES-22's three unit-test scripts: structured-output validation (23), delegation-receipt integrity (20), rejection-event logging (21).
38/39
Adversarial tests passed against the Omega Carrier agent-authorization API (cross-tenant isolation, lifecycle abuse, budget bypass, idempotency races). The one failure was a test-environment artifact, not a product defect.
100/100
Concurrent double-allocation attempts against a shared balance, correctly serialized with zero invariant violations.
106/106
Functional tests passed for the xISA capability-binding research prototype against the real LNES-22 engine — research-validated, not yet activated in production.
The live prompt-injection red team described above (Section 5) is the single strongest result on this page: a real adversarial run against a running system, not a tabletop exercise. It is reproducible and has been run twice.

The LNES-03 defense matrix.

Separate from the Consequence Boundary work above, ExergyNet's production settlement layer carries its own hardened design.

01

Unidirectional Capital Sump

The LNES-03 contract accepts only native SOL; transient accounting tokens are minted and instantly burned. No liquidity pool exists to be drained.

02

Ed25519 M2M Middleware

  • Replay Guard8-byte nonce + in-memory cache
  • Temporal Lock60-second Unix timestamp window
  • SignatureEd25519 proof-of-identity
03

ZK-STARK Compute Verification

RISC Zero zkVM generates ZK-STARK proofs of compute execution. Altered logic invalidates the proof.

STATUS NOTICE — ZK Compute Settlement

ZK-STARK compute settlement is operating in testnet mode. Status labels above reflect the target ExergyNet compute architecture. On-chain ZK proof verification for the compute grid is in development. See On-Chain Proof for current contract and verification status.

Test Your Agent Against the Consequence Boundary

Bring an autonomous system, tool chain, or machine workflow. ExergyNet evaluates what it can access, what authority it possesses, and whether prohibited consequences remain enforceably outside that authority.