As AI agents accelerate in capability, we need the equivalent of deceleration: a checkpoint that stops them from executing consequential actions without authorization. Solvent is that authorization layer.
AI systems are becoming increasingly capable of planning, reasoning, using tools, operating software, and pursuing goals with limited supervision.
The hard problem is no longer simply whether an agent can perform an action.
The harder question is:
Should this particular action be allowed to happen, right now, against this exact target, under this exact authority?
That distinction became the foundation of Solvent.
Solvent is not an agent firewall, a generic policy engine, or another layer of prompting. It is a small authority layer between autonomous systems and consequential actions.
Its job is deliberately narrow:
Let intelligence move fast while forcing consequences through a durable authorization checkpoint.
This writeup captures the most important architectural insights that emerged from the project's earliest ideas through the eventual kernel freeze and post-freeze security review.
1. The Core Insight: Intelligence Needs a Brake
1.1 Capability and authority are different things
- Capability — the system can perform an operation.
- Intent — the system wants to perform an operation.
- Evidence — the system has information supporting the operation.
- Belief — the system currently regards some claim as sufficiently established.
- Authority — the system is actually permitted to cause the consequence.
The critical distinction is:
Evidence is not authority. Intent is not authority. Capability is not authority.
An agent may present convincing evidence, generate a plausible justification, or formulate a perfectly reasonable plan. None of those facts should automatically become permission.
1.2 The authorization checkpoint
intelligence
│
▼
┌───────────────────┐
│ AI agent / │
│ autonomous │
│ workflow │
└─────────┬─────────┘
│ proposed consequence
▼
┌───────────────────┐
│ SOLVENT │
│ authorization │
│ checkpoint │
└─────────┬─────────┘
│
authorized? ─── no ──► STOP
│
yes
│
▼
┌───────────────────┐
│ external executor │
│ / real-world │
│ consequence │
└───────────────────┘
Solvent does not attempt to make the agent intelligent. It makes the consequence conditional on authority.
1.3 Deceleration is the right metaphor
AI systems are accelerating in:
- reasoning,
- tool use,
- action space,
- autonomous run length,
- operational reach.
The missing complement is deceleration:
- a place where action can be stopped,
- a place where authority can be checked,
- a place where stale or revoked permission can invalidate an action,
- a place where exact target binding prevents confused-deputy failures.
Solvent is designed around that missing function.
2. Keep the Kernel Small
One of the strongest conclusions of the project was that the security kernel should become smaller, not larger, as the ecosystem grows.
2.1 The kernel is a trusted authority core
The kernel is deliberately limited to durable facts and atomic transitions that must be trustworthy.
At a high level, it governs:
- beliefs,
- evidence,
- debt,
- targets,
- snapshots,
- activations,
- revocations,
- action intents,
- authorization,
- claiming and execution state transitions.
The kernel does not attempt to understand every domain.
2.2 The kernel growth rule
New capabilities default to the service, adapter, executor, deployment, policy, demo, or documentation layers. Kernel changes require a genuinely new durable security fact or atomic security transition that cannot safely be expressed outside the existing kernel.
This prevents a recurring anti-pattern:
“This feature is security-related, therefore it belongs in the kernel.”
The right question is:
Does this introduce a new durable security fact or atomic security transition that the frozen kernel cannot safely represent?
If not, it belongs elsewhere.
2.3 The extension decision tree
External product / protocol
│
└──► Adapter
Policy / orchestration / composition
│
└──► Service / Policy
Execution / infrastructure
│
└──► Executor / Deployment
Customer-specific behavior
│
└──► Policy / Configuration / Data
Reporting / UI / analytics
│
└──► Product / Read Model / Service
Impossible database state
│
└──► Database invariant
New atomic security primitive
│
└──► Kernel only if unavoidable
Everything else
│
└──► Don't add it
3. Retrieval Is Not Authority
The foundational distinction is simple:
Retrieving information does not grant permission to act on it.
Autonomous systems routinely retrieve documents, telemetry, approvals, tool responses, and other agent outputs. Those inputs can influence a decision. They should not silently become authority.
The normal agent loop:
retrieve → reason → decide → call tool
becomes:
retrieve → reason → propose → authorize → call tool
The important difference is that proposal and authority remain separate.
3.1 Agentjacking made this concrete
A hostile input can attempt to manufacture something that looks like:
- an approval,
- a trusted instruction,
- a policy conclusion,
- a recommendation,
- a deployment request.
Solvent treats that content as evidence or claims until the appropriate authority state exists.
A statement about permission is not itself permission.
4. The Belief Ledger Separates Epistemic State from Authority
The belief model provides a durable way to represent what the system currently believes without automatically making that belief actionable.
4.1 A belief is a claim, not a permission
Conceptually:
Belief
├── claim
├── claim type
├── evidence
├── status
└── debt
A belief can represent a statement about software, infrastructure, security, compliance, or another domain.
The belief itself does not become execution authority.
4.2 Epistemic kinds
The model distinguishes:
- Postulated — introduced as an assumption or starting point.
- Accommodated — accepted because the current model or evidence requires it.
- Derived — obtained from other accepted claims or evidence.
The distinction records something about how a claim entered the reasoning process.
4.3 Debt as incomplete verification
A belief can exist while carrying unresolved obligations.
Examples:
- provenance still needs checking,
- contradictions still need investigation,
- blast radius still needs assessment,
- rollback planning still needs validation,
- version pinning still needs completion,
- operator review still needs completion.
The crucial design decision was to make debt opaque vocabulary, rather than encode one deployment's vocabulary inside the kernel.
The kernel only needs the structural rule:
A belief can be promoted when its debt is empty.
The vocabulary belongs to the application, policy, or deployment.
4.4 Why this scales
The same mechanism can support:
- software deployment,
- infrastructure changes,
- database migrations,
- production configuration,
- autonomous research,
- compliance workflows,
- enterprise change management.
The kernel does not need to know the domain language.
5. Authority Must Bind to the Exact Consequence
A vague relationship such as:
belief → action
is insufficient.
The exact target and exact approved state matter.
5.1 The confused-deputy problem
Suppose:
Target T1
Snapshot S1
is approved.
An agent later attempts:
Target T2
Snapshot S2
A loose authorization check can accidentally authorize the wrong consequence.
5.2 Exact authority identity
Solvent therefore treats the authority instance as effectively:
(target_id, snapshot_id)
The action intent is bound to that exact identity.
The database reinforces the relationship through structural constraints.
5.3 The database as a security primitive
The database is not the policy engine.
But it should make impossible security states structurally difficult or impossible to represent.
Examples include:
- scenario isolation,
- unique active relationships,
- exact authority binding,
- valid snapshot references,
- intent state transitions,
- duplicate prevention.
When a security relationship can be expressed as structure, prefer structural enforcement over convention.
6. Authorization Is Not Execution
Another critical separation became explicit:
AUTHORIZE != EXECUTE
Authorization asks:
Is this consequence currently permitted?
Execution asks:
Did the external system actually perform it?
Those are different facts.
6.1 The execution path
Prepare
↓
Authorize
↓
Claim intent
↓
Invoke external executor
↓
Observe provider outcome
↓
Complete / rollback / reconcile
Solvent does not claim that an authorization result proves an external side effect occurred.
6.2 External providers remain a boundary
The first real executor integration demonstrated the model:
Solvent
│
├── evaluates authority
├── binds exact target/snapshot
├── claims exact intent
│
▼
GitHub executor
│
▼
workflow_dispatch
The executor consumes authority. It does not create it.
7. Tokens Are Not Authority
A workflow token can provide continuity or correlation.
It should not silently become a permission primitive.
Hence:
TOKEN != AUTHORITY
Consequential operations must re-read current state rather than treating stale workflow context as permanent authority.
This matters for:
- revocation,
- stale authorization,
- long-running workflows,
- retries,
- asynchronous execution,
- distributed systems.
8. Authorization Is Temporal
An action that was acceptable earlier may no longer be acceptable now.
Targets can change.
Snapshots can change.
Authority can be revoked.
The system should therefore ask:
Is the exact thing being attempted still authorized under the current authority state?
rather than merely:
“Was this approved at some earlier point?”
This creates a natural safety boundary around:
- stale approvals,
- revoked targets,
- changed infrastructure,
- changed configuration,
- changed security conditions.
9. Race Conditions Are Part of the Architecture
A serious authorization system must model concurrency rather than assume sequential execution.
9.1 Authorization versus claiming
There is a residual race between authorization and intent claiming.
The key invariant is:
No provider side effect occurs before successful claiming of the exact intent.
9.2 Claim versus provider execution
Once a third-party provider is involved, the provider participates outside Solvent's transaction boundary.
The architecture therefore distinguishes:
Solvent can make its own transitions atomic.
Solvent cannot make an external provider transactionally atomic.
9.3 Revocation races
The service-layer principal liveness check for debt retirement is intentionally best-effort:
principal active
↓
authorization pre-check
↓
principal revoked
↓
kernel mutation
That race is documented rather than hidden behind a false claim of atomicity.
Name residual races, bound them, and document them honestly.
10. Trust Boundaries Matter More Than Abstraction Boundaries
The key question is not:
“Is this logic in the kernel?”
It is:
Which layer becomes part of the trusted computing base when bypassing or corrupting it can produce an otherwise unauthorized consequential action?
A representative trust flow is:
Domain semantics
↓
Policy / verifier / review
↓
Kernel
↓
Database
↓
Executor
↓
External consequence
10.1 Five bypass vectors
-
Direct kernel calls
- Can an untrusted actor invoke authority-changing operations directly?
-
Alternate authority APIs
- Does another interface expose the same mutation without policy enforcement?
-
Lower-level service bypass
- Can internal code skip the service/policy boundary?
-
Direct database writes
- Can someone with DB credentials bypass the application?
-
Deployment/configuration exposure
- Does the environment expose capabilities that the architecture assumes are trusted?
The important conclusion is:
A policy is not real merely because it exists in one API handler.
Its trustworthiness depends on the actual paths through which consequential state can change.
11. Domain Semantics Belong Above the Kernel
The later Oracle/physics work sharpened this boundary.
Suppose:
Claim C
valid under A, B, C
A binary promoted/unpromoted state cannot express every semantic applicability relationship.
That does not automatically justify making the kernel understand physics, business policy, or other domain logic.
The better model is:
domain claim
↓
domain verifier / policy
↓
attestation
↓
Solvent authority checkpoint
↓
execution
Semantic applicability is policy. Durable authority is kernel state.
11.1 Attestations must have trustworthy dependencies
For example:
Policy P17
↓
Attestation A42
↓
Action authorization
The fact that A42 is valid under P17 is itself a meaningful claim.
The general lesson:
Every security-relevant policy dependency should have a truthful trust model rather than a magic label.
12. Human Review Is Policy, Not a Universal Kernel Rule
It is tempting to encode:
humanReviewed = true
as a universal kernel requirement.
That would hardcode one organization's governance model.
The better design is to represent human review as a policy obligation through the generic debt/authorization machinery.
One deployment may require:
needOperatorSignoff
Another might require:
needSecurityApproval
Another may permit fully automated operation within a constrained risk domain.
Governance vocabulary belongs to policy; the kernel should enforce the durable structure.
13. Actor Type Is Not Identity
The actor model may distinguish:
HUMAN
AGENT
SYSTEM
But actor category does not prove identity.
Likewise:
actor_type = HUMAN
inside a request cannot be trusted as authentication.
The correct relationship is:
authentication boundary
↓
trusted principal identity
↓
policy / service
↓
kernel mutation
Authentication, identity, actor type, and authorization remain separate concepts.
14. Audit Is Evidence of What Happened
Audit records should describe actual events rather than manufacture reassuring narratives.
Useful event distinctions include:
- authorization granted,
- authorization denied,
- adapter invocation,
- provider response,
- execution result,
- debt retirement,
- belief promotion.
14.1 No false audit
A rejected impersonation attempt should result in:
403
0 mutation
0 discharge rows
0 misleading success audit
The audit trail must not claim that an action happened when it did not.
14.2 Observability is not a reason to enlarge the kernel
The architecture accepts that some post-commit audit failures can occur independently from core state mutation.
That does not automatically justify moving all observability into the kernel.
Do not grow the authority core merely to perfect secondary observability unless the threat model requires it.
15. Flagship Security Stories
15.1 Agentjacking
Problem: malicious or poisoned content tries to manipulate the agent into treating text as authority.
Solvent response:
tool output
↓
evidence
↓
policy / verification
↓
authority checkpoint
↓
action only if authorized
Theme: Evidence is not authority.
15.2 Lying Agent
Problem: an agent claims that something is approved or safe when it is not.
Solvent response: the statement remains a claim until the durable authority state says otherwise.
Theme: An agent's assertion is not an authorization record.
15.3 Stale Authorization
Problem: the environment changes after approval.
Solvent response: re-evaluate current authority.
Theme: Authorization has a state and a time dimension.
15.4 Confused Deputy
Problem: an action approved for one target is redirected to another.
Solvent response: exact target/snapshot binding.
Theme: Authorization must bind to the exact consequence.
15.5 Legitimate Autonomous Workflow
Problem: autonomous systems must still be allowed to work.
Solvent response:
evidence
↓
belief
↓
review / debt discharge
↓
promotion
↓
authority
↓
exact action intent
↓
authorization
↓
claim
↓
external execution
↓
audit / provider outcome
Theme: Solvent is not designed to stop automation. It is designed to make consequential automation accountable.
16. Where Solvent Provides the Most Leverage
Solvent is most valuable where software can cause consequences faster than humans can inspect every action.
Autonomous software deployment
Agents can analyze changes, tests, and release conditions before triggering production workflows.
Solvent can sit between:
agent decision
and
production consequence
with exact repository, workflow, ref, target snapshot, and authority checks.
Infrastructure automation
Examples:
- scaling production,
- modifying firewall rules,
- changing cluster configuration,
- altering cloud resources,
- performing infrastructure remediation.
The value is not simply “block risky actions.”
It is:
Bind an automated consequence to the authority state that actually approved it.
Database operations
Examples:
- schema migrations,
- data repair,
- bulk modifications,
- failover,
- destructive maintenance.
Solvent separates proposal from authorized mutation while preserving durable state.
Security operations
Examples:
- isolating hosts,
- revoking access,
- modifying security controls,
- responding to detections.
Telemetry can create evidence; it should not silently manufacture authority.
Financial and business workflows
Examples:
- refunds,
- payments,
- vendor changes,
- fund releases,
- billing modifications.
The authority checkpoint provides explicit boundaries around costly or irreversible consequences.
Autonomous research
Examples:
- launching expensive experiments,
- changing parameters,
- modifying shared infrastructure,
- publishing results.
Solvent separates research conclusions from permission to cause external consequences.
Multi-agent systems
Solvent is particularly useful where agents can:
- mislead one another,
- manufacture apparent approval,
- confuse roles,
- inherit unintended tool authority,
- exploit another agent's permissions.
The key value is an external authority boundary that prevents one agent's assertion from becoming another agent's permission.
Compliance and governed automation
Organizations can keep their existing governance process while using Solvent as the durable technical checkpoint between approval and consequence.
17. What Solvent Should Not Become
Not an agent firewall
The core question is narrower:
Is this consequential action authorized?
Not a universal policy language
Policy belongs above the kernel unless a durable invariant genuinely requires kernel enforcement.
Not a reasoning engine
Solvent should not decide whether a scientific proposition, business judgment, or domain conclusion is correct.
Not an all-purpose workflow engine
Workflow sequencing can live above the kernel. The kernel preserves trusted state and authority transitions.
Not an observability platform
Reporting and analytics should consume Solvent state rather than enlarge the security core.
Not a credential vault pretending to be authority
Authentication proves identity.
Authorization proves permission.
Execution credentials perform operations.
Those concepts must remain distinct.
18. The Ecosystem Vision
The long-term vision is larger than the kernel.
The kernel is the nucleus. The ecosystem grows outward from it.
┌──────────────────────┐
│ Products │
│ dashboards / policy │
│ compliance / reports │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Policy / Verifier │
│ domain semantics │
│ human review │
│ attestations │
└──────────┬───────────┘
│
┌───────────────────────▼───────────────────────┐
│ SOLVENT │
│ frozen authority kernel │
│ │
│ beliefs • evidence • debt • authority │
│ targets • snapshots • intents • revocation │
└───────┬─────────────┬─────────────┬───────────┘
│ │ │
┌─────▼────┐ ┌─────▼────┐ ┌─────▼─────────┐
│ Adapters │ │ Executors│ │ Deployments │
│ providers│ │ actions │ │ auth / trust │
└──────────┘ └──────────┘ └───────────────┘
The vision is an ecosystem where autonomous software can remain highly capable without receiving unrestricted authority by default.
19. The Extension Mechanism
The ecosystem should grow through disciplined extension rather than continual kernel expansion.
19.1 Adapters
Adapters translate external systems into Solvent concepts.
Examples:
- Sentry,
- GitHub,
- cloud providers,
- CI systems,
- security scanners,
- ticketing systems,
- observability platforms,
- enterprise identity systems.
Principle: Translate at the boundary; keep provider semantics out of the authority core.
19.2 Services and policy layers
The service layer composes Solvent primitives into organizational behavior:
- approval policies,
- risk classification,
- human-review requirements,
- applicability rules,
- tenant policies,
- governance,
- orchestration,
- compliance controls.
These layers can evolve without destabilizing the kernel.
19.3 Executors
Executors turn an authorized intent into an external consequence.
Examples:
GitHub Actions
Cloud API
Database migration
Infrastructure controller
Security response platform
Payment system
Principle: Execution consumes authority; it does not create authority.
19.4 Deployment integrations
Identity, authentication, credential management, isolation, and transport trust belong largely to deployment architecture.
That lets Solvent fit into:
- local processes,
- services,
- enterprise APIs,
- MCP deployments,
- hosted control planes,
- internal platforms.
19.5 Policy and configuration
Customer-specific behavior should be configuration or policy rather than kernel code.
This includes:
- what requires human review,
- what counts as risky,
- which actors can initiate an operation,
- what evidence is sufficient,
- which obligations must be discharged,
- which actions require confirmation.
19.6 Demos and adversarial scenarios
A good Solvent demo should show a plausible autonomous action being rejected at the authority checkpoint.
Future adversarial scenarios include:
- poisoned evidence,
- fabricated approval,
- hallucinated authority,
- wrong actor,
- wrong target,
- stale authority,
- revoked authorization,
- malformed provider output,
- invalid token,
- unauthorized execution.
These demonstrations make the invisible value of the checkpoint visible.
20. Oracle: A Model for Domain-Specific Extensions
The Oracle/physics-verification work provided a model for extending Solvent without polluting the kernel.
Oracle can contain:
- explorer agents,
- attacker agents,
- verifier/judge agents,
- human review,
- domain evidence,
- domain policies,
- attestations,
- scenarios.
The architecture becomes:
Oracle knows physics semantics.
Solvent knows authority semantics.
They meet at the checkpoint.
The same model can support ecosystems for software supply chains, cybersecurity, infrastructure, finance, research, and enterprise change management.
21. MCP as an Ecosystem Surface
MCP is useful as an integration surface because agent systems can consume Solvent capabilities as tools.
But the security boundary remains deployment-specific:
local trusted MCP
≠
remote public MCP
A remote MCP deployment requires explicit authentication and boundary controls.
Transport concerns should not be pushed into the authority kernel merely because an integration uses MCP.
22. Prefer Structural Truth
Across the entire project, one principle kept recurring:
Do not rely on labels where the system can enforce the relationship structurally.
Actor identity
Bad:
actor_id supplied by caller
Better:
identity derived from trusted authentication context
Authority binding
Bad:
something was approved for this target
Better:
intent is structurally bound to target_id + snapshot_id
Debt
Bad:
deployment code remembers which debt items exist
Better:
kernel treats debt as opaque and promotion depends on emptiness
Execution
Bad:
authorization response implies execution
Better:
authorization → claim → provider call → actual outcome
Audit
Bad:
request attempt recorded as success
Better:
audit event corresponds to the actual mutation/event
This is the difference between a system that describes security and one that enforces it.
23. Why the Kernel Was Worth Freezing
The final architecture demonstrated that new security requirements could be addressed without reopening the authority core.
The pattern became:
new security requirement
↓
ask whether kernel growth is necessary
↓
determine the correct upper-layer boundary
↓
implement outside kernel
↓
regression-test kernel invariants
↓
freeze remains intact
That is the real value of the freeze.
The kernel is no longer the place where every future security concern must be solved.
It is a stable foundation on which the ecosystem can evolve.
The post-freeze review found no unresolved Critical, High, or Medium security defect. REST authorization behavior was verified, audit provenance was correct, the exact authority binding remained intact, and the kernel received no semantic changes.
The verification also covered the full test suite, race testing, database reset, raw-write hygiene, isolation, and MCP verification.
24. The Solvent Mental Model
The entire system can be compressed into one sequence:
CAN THE AGENT?
│
▼
capability
│
▼
DOES IT CLAIM?
│
▼
intent
│
▼
WHY?
│
▼
belief + evidence
│
▼
IS THE BELIEF READY?
│
▼
debt = empty
│
▼
IS THERE AUTHORITY?
│
▼
exact target + snapshot
│
▼
IS AUTHORITY STILL VALID?
│
├── NO ──► STOP
│
YES
│
▼
CLAIM THE INTENT
│
▼
CALL EXTERNAL EXECUTOR
│
▼
RECORD WHAT HAPPENED
This is the conceptual heart of Solvent.
25. The Ecosystem Thesis
The deeper thesis is not that AI agents should become less capable.
It is almost the opposite.
AI agents should be allowed to become extraordinarily capable.
But capability should not imply unrestricted consequence.
The ecosystem should therefore evolve toward a world where:
Agents become faster.
Agents become smarter.
Agents become more autonomous.
Agents receive more tools.
BUT
Consequential authority remains explicit.
Solvent becomes the layer where an autonomous system crosses the boundary from:
“I believe I should do this.”
to:
“I am authorized to cause this consequence.”
That boundary becomes increasingly important as software moves from assisting humans to acting on their behalf.
26. The Vision
The long-term vision for Solvent is an ecosystem in which authorization becomes a reusable infrastructure primitive for autonomous computing.
Not an agent framework.
Not a chatbot wrapper.
Not another policy dashboard.
A common authority substrate.
A world where:
- agents can be highly autonomous,
- domain verifiers can be highly specialized,
- policies can evolve independently,
- adapters can connect external systems,
- executors can operate real infrastructure,
- organizations can define their own governance,
- and the final consequential transition still passes through a durable authorization boundary.
The architectural promise is deliberately modest:
Solvent does not decide what the world should do. It decides whether the system is authorized to do the particular thing it is about to do.
That modesty is the feature.
The smaller the trusted authority core, the easier it is to reason about.
The richer the ecosystem around it, the more useful it becomes.
27. Closing: Build the Brake Before the Engine Gets Faster
The next generation of software will not simply compute.
It will negotiate.
It will deploy.
It will modify.
It will purchase.
It will publish.
It will administer.
It will operate infrastructure.
And increasingly, it will do these things without waiting for a human to click every button.
The central engineering question therefore changes.
It is no longer sufficient to ask:
“How do we make agents capable of doing more?”
We must also ask:
“Where is the checkpoint that stops capability from becoming unauthorized consequence?”
That is the problem Solvent is built to solve.
AI acceleration is inevitable.
Authorization must provide the deceleration.
One-line thesis
Solvent is the authorization checkpoint for autonomous systems: a small, durable authority layer that lets AI agents move fast while preventing consequential actions from proceeding without explicit, current, exact authorization.
Top comments (0)