Inspiration

ConstantGate began as a research project.

I was investigating whether a supported software operation could retain a bounded runtime path as the surrounding state population increased. The result appeared to follow an O(1) profile, but I did not accept that conclusion immediately. I tested for hidden scaling through caching, fixed data, compilation, memory growth, and broader state dependence.

That work led to a broader principle:

Once a request enters a formally declared operational envelope, the information required for the supported decision can be represented in bounded state rather than repeatedly rediscovered across the wider system.

Applied to enterprise authorization, that principle produced ConstantGate.

What it does

ConstantGate is an SDK for deterministic operational authority around enterprise AI agents.

The model may reason, interpret context, and propose an action, but it cannot declare its own identity, approval, trust state, or authority.

ConstantGate separates:

Model-generated proposal
        +
Authenticated Agent Passport
        +
Current trusted enterprise state
        ↓
Compiled authority evaluation
        ↓
ALLOW or DENY

The Agent Passport identifies the agent’s tenant, sponsor, role, session, and permitted scope. Current approvals, MFA, device trust, workflow state, and revocation status come from authenticated enterprise systems.

An allowed decision issues a capability bound to the exact subject, action, resource, artifact, transition, expiry, and nonce. A denied request receives no execution authority.

How I built it

I designed ConstantGate around a compile-time and runtime separation.

At compile time, an organization defines supported identities, roles, actions, resources, trusted conditions, denial states, capability rules, revocation behavior, and audit requirements.

ConstantGate validates that definition and compiles it into an integrity-protected artifact.

At runtime, the application submits a structured proposal, attaches the Agent Passport and trusted enterprise context, and receives a bounded result:

ALLOW
reason: AUTHORIZED_TRANSITION
capability: ISSUED

or:

DENY
reason: SUBJECT_REVOKED
capability: NONE

The executor verifies and consumes an allowed capability. Reuse is denied as replay.

I used GPT-5.6 to develop and refine the SDK specifications, including the authority model, Agent Passport, trusted-context separation, capability semantics, revocation, replay protection, fail-closed behavior, audit structure, and verification criteria.

I then used Codex to implement those specifications, build the working SDK and demo, create the compiled-artifact workflow, and generate the test and verification tooling.

Demonstration

The demo uses an enterprise export-control scenario.

An AI agent recommends releasing a restricted technical dataset to an external partner.

In the first case, the trusted context shows a revoked subject:

Agent recommendation: PROCEED
ConstantGate: DENY
Reason: SUBJECT_REVOKED

In the second case, the subject is active and the required trusted conditions are present:

ConstantGate: ALLOW
Reason: AUTHORIZED_EXPORT
Capability: ISSUED

The governed executor verifies the capability and performs the exact approved release. A second use of the same capability is denied:

DENY
Reason: REPLAY_DETECTED

Enterprise use cases

  • Invoice authorization: binds authority to one invoice, amount, vendor account, approval state, and payment transition.
  • Database mutation: limits execution to the exact database, table, row, columns, case, and operation.
  • Critical due diligence: requires current legal, compliance, sanctions, recipient, document-scope, and signatory conditions before authorizing a release or transaction step.

The model reasons broadly. ConstantGate authorizes narrowly.

What I learned

A flat latency graph is not enough to establish bounded behavior. I had to distinguish between latency, actual computational work, preprocessing, memory cost, runtime behavior, and broader state population.

I also learned that computational constraints can produce security properties. A bounded authority path naturally requires:

trusted-state separation
closed operational envelope
default DENY
ALLOW or DENY outcomes
revocation
capability-backed execution
replay protection
auditable transitions

Challenges

The main challenge was claim discipline.

ConstantGate does not claim that all authorization or all computation is O(1). The public claim is limited to the tested environment, supported request class, declared operational envelope, compiled artifact range, and included evidence.

Another challenge was keeping authority outside the model. The model can propose an action, but authenticated organizational systems must supply the facts that determine whether it is permitted.

Accomplishments

The project includes:

  • a working SDK and enterprise demo;
  • an Agent Passport;
  • compiled authority artifacts;
  • deterministic ALLOW and DENY;
  • capability-backed execution;
  • replay protection;
  • revocation tests;
  • fail-closed handling;
  • audit evidence;
  • and benchmark exports.

What is next

Next steps include more enterprise workflow adapters, stronger verification, concurrency testing, direct hardware-counter and energy measurement, formal protocol documentation, and independent reproduction of the benchmark evidence.

The model proposes.

The Agent Passport identifies.

ConstantGate authorizes.

The enterprise executes only the exact transition the agent is permitted to perform.

Built With

Share this project:

Updates