Aegis / Identity, authority, and confinement

Give each agent session a verified identity, limit what it can access, and keep a signed record of important decisions.

A concrete example

An agent prepares a production deployment

Input

The named person, concrete deployment request, session key, policy, and declared filesystem and network scopes.

Action

Aegis issues the session credential, records the authority, and derives the supported operating-system limits from the signed scope.

Result

The reviewer receives a checkable identity, resolved enforcement state, and signed decision receipt.

What you receive

// 01

Session credential

A signed identity with the person and authority chain behind the session.

// 02

Resolved boundary

The supported filesystem and network controls that were actually applied.

// 03

Decision receipt

The concrete request, policy, decision, approver, and resulting record.

How it works

01
Name the session
Tie the agent session to a key, person, role, and declared scope.
02
Issue and log the credential
Sign the credential and record issuance in the transparency log.
03
Apply supported limits
Turn the declared scope into the supported operating-system enforcement available for the session.
04
Record the decision
Bind the concrete action and named decision to a signed receipt.

Inside the mechanism

// 001

Post-quantum-signed session identity

Aegis post-quantum signs the session credential and records its issuance in a tamper-evident transparency log. A signed chain names the person whose authority the session carries.

// 002

Holder binding and offline verification

A possession proof can show that the presenter holds the key committed at issuance. The credential, inclusion proof, and pinned trust roots can be checked without a callback to Athena or Aelethion.

// 003

Operating-system confinement

Aegis turns the signed scopes into operating-system limits applied to the session before it runs. Filesystem writes are the stable boundary. Some network controls have defined limits, and a few cannot be enforced at this layer.

// 004

Decision receipts

For a gated action, the receipt retains the digest of the concrete arguments, policy, decision, named approver, and time. It attests the decision and authority Aegis controls.

What it proves

Bounded claim

A verifier can check the issued session identity, transparency-log inclusion, named authority chain, holder proof where used, and the signed decision receipt against pinned roots.

What it does not prove

Permanent boundary

Post-quantum signatures protect identity and receipts. They are not encryption. The public-chain anchor remains classical. The enforcement layer does not provide destination-based network egress control, and unsupported controls cannot be described as enforced.

How it connects to Athena

Input

Trust root, session key, named identity, declared scopes, concrete action digest, policy, and correlation identifier.

Output

Credential, inclusion proof, resolved enforcement state, holder proof where used, and decision receipt.

Shared record

Athena joins the session identity and authority to the request, execution or refusal, evidence, and retained state.

Continue the review

Follow the enforced session into testing and recovery