Allowit: A Policy Engine for Delegated Work
Abstract
Allowit is a policy engine for work that agents do on an owner's behalf. It turns the owner's stated purpose into policy source, typed parameters and recorded state, all of which the owner can review.
Owners define the rules. Agents propose operations, which are checked in two places:
- The server gathers data from the marketplace, the web and models.
- A smart contract checks chain-native operations that the server authorized.
When the owner answers an uncertain question, the answer informs later uses of the same question. After review, it can also train specialist models offline. In this paper we look at several sample Stellar treasury Allowit policies to show how evaluation, recovery, cost accounting and organizational use work.
An agent that can search for services, pay for them and change a financial position can move work forward between an owner's decisions. Each of those steps commits something: money, a counterparty, a disclosure or a position. An agent can stay under its budget and still buy irrelevant stuff; that's exactly why we're building Allowit. Our research focuses on solving alignment of enforceable intent between owners and their agents.
Allowit records the owner's purpose as a policy and checks each operation against it at the point of execution. The owner reviews the policy’s source and parameters before installation, then uses the allowit CLI, SDK, authoring agent, or web app to configure and fund their agent’s wallets. They retain control at all times and can unilaterally close or drain their agent’s wallets. We explain below how this works.
Delegation and executable authority
An agent may encounter a new supplier or a changed position after its owner assigns the work. The owner cannot review every future instruction in advance. Delegation therefore needs rules that apply when the agent acts. Saltzer and Schroeder’s 1975 account of computer protection established two relevant principles: grant only the privileges a task needs, and check authority on every access.
OAuth 2.0, published in 2012, gives clients limited access through scoped, time-bounded authorization. The application still decides what that scope means for a particular action.
The 2014 Ethereum white paper describes executable state transitions. A policy wallet uses this structure to check asset, destination, amount and replay state as part of the transaction. The ledger enforces those conditions independently of the software proposing the operation.
x402 connects payment to service access: a server supplies payment requirements through HTTP 402, and the client retries with payment authorization. Allowit combines service discovery with policy evaluation around that exchange.
Component responsibilities
A limit set by an owner may appear in an editor, in the server's check before signing and in a contract's check during invocation. If each place kept its own copy of the rule, those checks could drift apart. The architecture gives them shared definitions while keeping evidence gathering, signing authority and native enforcement in the components responsible for those functions.
Owner interface
The , and let the owner state intent in natural language. Then delegates policy generation and presents results: the policy source code and editable typed parameters.
Evaluation
SDK core defines common types, rules and primitives. The SDK engine supplies shared execution logic to the CLI and server, so a rule such as daily_volume_limit retains one meaning across those surfaces.
Enforcement
Vendor packages bind assets and operations to exact native identities, contracts and signing semantics. The server authorizes an exact action using private context; the rail verifies the required signatures, policy identity, replay state, installed constraints, and observable asset effects.
Allowit provides a modular system of Rust and NPM packages that allow scalable extensibility across rails, models, and business needs.
For starter, we have: marketplace retrieval, web evidence, report fetching and model assessment implemented server-side with SQL storage, vector search, and split credentials. The result of running any of the supported policy functions reaches the ledger of a supported rail for contract enforcement. We illustrate here the high level architectural diagram of the system.
Onboarding interfaces
To make our system useful, we needed a user interface. Since we expect various groups of human users and agents to generate policies at different times, we decided to provide 3 main entry UI points. The web app, authoring agent (available over A2A and ACP interfaces) and the allowit CLI are 3 alternative for generating, reviewing and deploying policy artifacts. Execution can continue through an external agent harness after the owner installs the mandate.
Web app
A browser interface for entering intent, editing source and parameters, and reviewing the policy before owner signing.
ACP / A2A Agent
Our policy-authoring agent drafts and revises policies. Other agents can call it as a tool when they need authoring help.
CLI
A local interface for policy generation, validation, parameter editing and deployment. The executing harness can also use its commands.
Operations and delegated authority
An owner who gives an agent a signing key still has to decide which payments and conversions it may make, with whom, in what amounts and on what evidence. Allowit divides those decisions among four parties. The owner chooses the wallet, assets, counterparties, limits and executable policy.
An executing agent proposes a specific operation, and the server evaluates it against the approved policy and the relevant evidence. The wallet then verifies the required authorizations and enforces its native rules during execution. Because of this division, a policy can depend on a purchased report without any contract browsing the web.
The initial operation vocabulary comprises transfer, swap, deposit and redeem. These are distinct effect types, with different accounting and receipt requirements. They are not arbitrary contract calls. A wallet's executable advertises the operation types it admits; the owner's operations parameter selects a subset. The Custom policy in the worked example selects transfer, swap and redeem. A vault-deposit mandate selects an executable with deposit support and binds the approved vault and share floor.
| Economic operation | Exact effect and native checks | Delegated authority |
|---|---|---|
transfer | Transfer an exact quantity of the installed asset to the named recipient; apply recipient, amount, expiry and usage constraints. A paid report is a transfer followed by delivery verification. | Agent and server authorize the same request; wallet applies the installed policy. |
swap | Spend an exact input amount through the named router and token path, subject to a deadline and minimum output. On the explicit execute path, the wallet checks its observed input debit and output credit. | Agent and server authorize router, path, quantities and deadline; native policy constrains assets, venue and financial bounds. |
deposit | Supply an exact amount of the wallet asset to an approved vault and receive at least the specified share quantity into the wallet. The receipt records underlying debit and share credit. | Agent and server authorize vault, underlying amount and minimum shares; the selected wallet executable enforces deposit effects. |
redeem | Burn a bounded quantity of approved vault shares and receive at least the specified underlying amount into the wallet. The explicit execution path verifies the observed share debit and underlying credit. | Agent and server authorize vault, shares and minimum assets; the wallet verifies the effect before retaining the receipt. |
The distinction matters economically. A transfer for a consumed service is an expense. A swap or vault conversion moves value between assets or claims; its gross volume and irreversible expense are different quantities. Volume limits bound capital put through operations. Spending limits bound attributable expense, including applicable fees and conversion loss. Amounts use each asset's native integer units. A vault share quantity is not an underlying-token quantity, and a fee denominated in another asset requires authenticated valuation before it can be charged against an asset-denominated limit.
Canonical policy rules
Canonical rules compare authenticated request facts and prior usage with owner-selected constraints. The wallet’s selected enforcement placement determines which checks also run natively.
| Function | Constraint |
|---|---|
operations | Allowed native operation class |
tokens | Installed asset and swap token membership |
destinations | Approved recipient, router or vault |
payment_limit | Gross amount per operation |
lifetime_spending_limit | Cumulative irreversible expense |
daily_spending_limit | Irreversible expense per UTC day |
daily_volume_limit | Gross volume plus attributable gas per UTC day |
call_limit | Successful operation count |
expires_at | Owner and request expiry |
Evidence and assessment functions
Evidence functions run on the server. They retrieve material or assess a scoped question against preceding-call context; the standing analysis allowance bounds metered work.
| Function | Purpose |
|---|---|
marketplace_search | Retrieve candidate services with their sources |
internet_search | Retrieve public corroborating evidence |
fetch | Retrieve specified resource under expected-response binding |
systemone | Assess one scoped question against preceding call context |
price | Supply asset/amount-bound conversion input |
clear_systemone_context | Start a new classifier evidence window |
Configuration and state access
Configuration and stored policy state have distinct accessors. Updates participate in the native invocation’s atomic commit.
| Accessor | Effect |
|---|---|
ctx.params[key].ok() | Read a required typed owner value |
get_state | Read admitted policy state |
set_state | Stage a policy-state update |
Authoring and execution
The owner uses the web app, CLI or policy-authoring agent to draft or revise a policy, then reviews its source, settings and wallet permissions before approving deployment.
An executing agent uses Claude, Codex, Antigravity or a custom harness to propose actions, obtain the server’s decision and sign approved requests with its own key.
The external harness obtains SKILL.md from the Allowit server or uses the CLI to access the same operations. The skill describes the endpoint, public wallet profile, command sequence, policy inspection and operation recovery. A server-supplied skill contains no client private key because the server does not hold it. The customer can augment a local copy with credentials or use another client-controlled store; a dedicated secrets store is recommended. The instructions guide the harness, while authorization and native policy checks enforce its permissions.
Client keys and the server boundary
An executing agent signs with a key in client-controlled storage. The customer chooses how that key is stored: a secrets service, an environment var, or even just part of prompt are some possible choices.
We recommend a dedicated secrets store. Allowit’s server receives the public key and its authorization binding; it never receives or stores the client’s private key. The Allowit open source CLI + SDK offers a local fully auditable and client-configurable key-generation path. A possibility is using our CLI and separate public key metadata from a secret key file. The secret file should use (at least) mode 0600 inside a mode-0700 private directory.
The public wallet profile identifies the agent, wallet and policy binding; it contains no seed. The server stores the public key and its authorized binding, not the client's private key. A local signing process can hold the key without placing its raw bytes in the language model's context.
The server evaluates requests through scoped interfaces. Those interfaces expose the submitted operation, the permitted decision or explanation, and the operation's status or receipt. They do not provide an executing agent with database access, private feedback records, unrelated owners' context or provider credentials. The server can use private evidence during an assessment without returning the underlying records.
An agent-key compromise alone does not supply the server's authorization. A server-key compromise alone does not supply the agent's authorization. Both parties can still approve an undesirable operation, and both can collude; the native policy continues to enforce the constraints actually installed in the wallet. This makes placement consequential. An on-chain recipient allowlist or output floor remains enforceable under that collusion. A server-only judgment about report quality depends on the server's assessment. The paper's worked policy assigns deterministic financial constraints to the wallet and contextual assessment to the server for that reason.
Owner administration follows a separate path. The owner can pause delegated execution, change the approved configuration or use the defined recovery authority without asking the executing agent to approve its own removal. Configuration changes advance their version and preserve accounting and replay protection. Delegated signatures do not confer these owner powers.
Native enforcement
The financial constraints that must hold if the agent or server makes a overly permissive mistake can be compiled into a Common or Custom policy contract and checked each time the wallet is invoked.
The next policy in this example evaluates authenticated operation facts against installed parameters and recorded usage, without making network requests. It first applies shared checks: the permitted operation, the asset, the expiry, expense and daily volume (supported by both Common and Custom contracts). It then branches by operation type (supported in Custom contracts only).
Transfer
The transfer branch admits a payment only when its recipient belongs to evidence_sellers and its gross amount passes payment_limit under report_limit. A transfer to an exchange or vault therefore fails unless that address is also an approved evidence seller. The shared checks still apply: operation, asset, expiry, lifetime and daily expense, and daily volume. Passing these financial checks permits the bound payment; the host separately assesses the report’s relevance, binds the purchased service and terms, and records whether the report actually arrives.
Swap
The swap branch checks swap_venues and swap_limit, then reads typed reserve, floor and output-asset parameters. The request must spend the installed asset and receive the configured token. Reserve must be nonnegative, floor positive, remaining daily capacity at least reserve, and signed min_out at least floor. The host also checks that this minimum satisfies the owner’s slippage tolerance against the accepted reference quote. It binds that minimum into the authorized request; explicit native execution verifies the resulting output. A swap can pass its payment cap yet fail the capacity reserve.
Redeem
The redeem branch checks the vault against the owner’s approved set. A zero share_limit leaves shares uncapped; a positive value bounds request.amount_in, and a negative value denies. The additional policy output floor must be nonnegative, and request.min_out must meet it. Native redemption still requires positive shares and positive minimum asset output. Shares and underlying assets use their own units. Explicit execute verifies the underlying credit rather than trusting the vault’s reported payout. Any later conversion uses the amount actually received and requires its own authorization.
Result and execution
An operation outside the selected branches is rejected; if it reaches the final match arm, the policy panics. Every rule error in this source propagates, and a failed assertion or required typed read aborts evaluation. Native failure rolls back the invocation’s effects. Returning Ok(()) means only that this request passed the policy; it neither submits a transaction nor purchases a service. Host orchestration prepares the operation through its vendor package, collects signatures, persists signed bytes, submits them and reconciles the outcome. Report delivery requires separate evidence.
use allowit::prelude::*;
const EVIDENCE_SELLERS: &str = "evidence_sellers";
const REPORT_LIMIT: &str = "report_limit";
const SWAP_VENUES: &str = "swap_venues";
const SWAP_TOKEN: &str = "swap_token";
const SWAP_LIMIT: &str = "swap_limit";
const RESERVED_VOLUME: &str = "reserved_volume";
const SWAP_OUTPUT_FLOOR: &str = "swap_output_floor";
const VAULTS: &str = "vaults";
const SHARE_LIMIT: &str = "share_limit";
const REDEEM_OUTPUT_FLOOR: &str = "redeem_output_floor";
/// Buy evidence only from approved sellers. Rebalance through approved exchanges,
/// retaining capacity for later work. Redeem only approved vault positions.
/// Bound expenses, volume, assets, expiry and each operation's native effects.
pub fn execute(ctx: &AllowitContext) -> allowit::Result {
let operation = allowit::operations(ctx, &ctx.params[allowit::OPERATIONS].ok())?;
allowit::tokens(ctx, &ctx.params[allowit::TOKENS].ok())?;
allowit::expires_at(ctx, &ctx.params[allowit::EXPIRES_AT].ok())?;
allowit::lifetime_spending_limit(ctx, &ctx.params[allowit::LIFETIME_SPENDING_LIMIT].ok())?;
allowit::daily_spending_limit(ctx, &ctx.params[allowit::DAILY_SPENDING_LIMIT].ok())?;
let remaining = allowit::daily_volume_limit(ctx, &ctx.params[allowit::DAILY_VOLUME_LIMIT].ok())?;
match operation {
"transfer" => {
allowit::destinations(ctx, &ctx.params[EVIDENCE_SELLERS].ok())?;
allowit::payment_limit(ctx, &ctx.params[REPORT_LIMIT].ok())?;
}
"swap" => {
allowit::destinations(ctx, &ctx.params[SWAP_VENUES].ok())?;
allowit::payment_limit(ctx, &ctx.params[SWAP_LIMIT].ok())?;
let reserve: i128 = ctx.params[RESERVED_VOLUME].ok();
let floor: i128 = ctx.params[SWAP_OUTPUT_FLOOR].ok();
let output: Address = ctx.params[SWAP_TOKEN].ok();
assert!(ctx.request.token_in == ctx.request.asset);
assert!(ctx.request.token_out == Some(output));
assert!(reserve >= 0 && floor > 0);
assert!(remaining >= reserve);
assert!(ctx.request.min_out >= floor);
}
"redeem" => {
allowit::destinations(ctx, &ctx.params[VAULTS].ok())?;
let shares: i128 = ctx.params[SHARE_LIMIT].ok();
let floor: i128 = ctx.params[REDEEM_OUTPUT_FLOOR].ok();
assert!(shares == 0 || (shares > 0 && ctx.request.amount_in <= shares));
assert!(floor >= 0 && ctx.request.min_out >= floor);
}
_ => panic!("unsupported operation"),
}
Ok(())
}
- Typed input
- Result
| Rule | Input | Typed result |
|---|---|---|
| operations | request.operation; owner operations | Result<&'static str>Ok("swap") |
| tokens | installed asset; output asset; allowed assets | Result<Address>Ok(installed_asset) |
| expires_ | owner expiry; request expiry; authenticated now | Result<u64>Ok(owner_expiry − now) |
| lifetime_ | lifetime expense; request.spent_units; owner lifetime limit | Result<i128>Ok(lifetime_limit − lifetime_spent − spent_units) |
| daily_ | UTC-day expense; request.spent_units; owner daily expense limit | Result<i128>Ok(daily_limit − day_spent − spent_units) |
| daily_ | UTC-day gross volume; request.amount; attributable gas; owner volume limit | Result<i128>Ok(volume_limit − day_total − amount − gas_units) |
| match operation | operation = "swap" | branch selectionEnter "swap" |
| destinations | request.recipient; owner swap_venues | Result<Address>Ok(approved_venue) |
| payment_ | request.amount; owner swap_limit | Result<i128>Ok(swap_limit − amount) |
| ctx.params[key].ok() | reserved_volume | i128reserve |
| ctx.params[key].ok() | swap_output_floor | i128floor |
| ctx.params[key].ok() | swap_token | Addressapproved_output_asset |
| assert! | token_in == asset | ()Pass |
| assert! | token_out == Some(output) | ()Pass |
| assert! | reserve >= 0 && floor > 0 | ()Pass |
| assert! | remaining >= reserve | ()Pass |
| assert! | min_out >= floor | ()Pass |
| Ok(()) | all evaluated checks passed | allowit::ResultOk(()) |
Beneath the business rules, the custody kernel enforces its own invariants: policy and module identity, network, installed asset, signer authority, pause, expiry, version, nonce and replay. These apply whether or not a policy lists any particular rule.
Execution costs
Each operation draws on independently priced services and network resources. The engine retains the applicable tariff or accepted quote with the decision, so the owner can attribute incurred costs to the work that caused them.
Server compute and storage
+ retained bytes × rate
The host operator prices execution, records and storage retention. The owner’s billing arrangement determines which costs are attributed to a mandate.
Marketplace indexing and retrieval
The marketplace operator meters indexing, retrieval and retention, or allocates them within the host service. Discovery does not purchase the selected service.
Web search and fetching
The search or retrieval provider sets the tariff. The standing analysis allowance admits paid evidence calls before they occur.
Model inference
+ output units × output rate
The selected model provider sets its usage tariff. Assessment costs remain attributable when a later operation is denied.
Purchased services and venues
The seller sets service terms; the exchange or vault defines its charges. Each accepted payment binds its recipient, asset and amount. x402 payment terms.
Network execution and storage
+ storage rent / restoration
The network sets resource pricing. Transaction simulation estimates resources and restoration requirements for the exact proposed invocation. Stellar fee model.
Stellar charges fees in lumens (XLM). One lumen equals 10⁷ stroops. A classic operation costs at least 0.00001 
for inclusion, with higher fees during congestion. Contract transactions also pay for computation, ledger access and storage rent. Before signing, the wallet simulates the invocation to estimate its resource fee. Account reserves remain part of the account balance. Stellar fee schedule · Transaction simulation
Allowit could sell subscriptions to its hosted policy engine and meter searches, model calls and other analysis against the owner’s research budget. That work incurs costs even when the engine denies the proposed action. For a marketplace purchase, Allowit could disclose its service fee alongside the seller’s price in the quote the owner authorizes. Institutions could also pay for private deployments, support and model adaptation using records they authorize for training.
Organizational capacity
A small treasury team may understand a position change yet lack the staff to coordinate its research, purchases, reviews and execution. Allowit lets agents carry that sequence forward under an owner-defined policy.
Manidis and Roberts frame the broader economic question around the institutions and controlled positions through which model capabilities become useful. The engine supplies a mechanism for delegating consequential work while keeping authority and execution reviewable.
A larger organization may want a capital movement to pass an operating policy, a departmental budget authority and a risk reviewer, and for exceptional requests an accountable person, before it executes. Such a chain can replace the single server approval.
An owner can assign an executing agent the owner-signing role for a subordinate wallet. That agent can appoint another executing agent and fund its work through a separately authorized parent transfer. Each wallet checks its own agent-and-server authorization and installed policy. Parent funding authorization bounds the transfer; the child’s installed policy governs subsequent execution. When A owns the child, A controls its configuration. Alternatively, making the parent policy wallet the child’s owner routes child administration through the parent’s policy checks.
The retained record connects evidence, classifier judgments, owner answers, signed terms and observed outcomes. New staff or agents can inherit this context; authorized records also support discovery and reviewed training. Explicit research, expense and volume allowances let the owner allocate scarce resources and revise limits without erasing prior commitments.
The same structure supports teams buying data, monitoring, storage or computing services. Agents find providers and compare terms; exceptions return to the responsible owner. Authorization applies to the supported operation. If later use of a purchased resource also needs constraints, those calls require their own governed execution path.
We believe that we are at the Dawn of a new era of agentic value creation. As new flywheels accelerate with less friction than we thought possible even a few years ago, small hybrid teams will perform work of previously unimaginable complexity in record time. To enable this momentum, we’ll need new self-balancing systems that keep our algorithmic cars from tipping over as they turn into hyperloops. Allowit sees itself as one of the foundational research and development collectives building the axles that will carry us along the rails of the future.
References
- Allowit Core
- Allowit SDK
- Allowit contracts for Stellar
- x402: An Open Standard for Internet-native Payments
- Distilling the Knowledge in a Neural Network
- Saltzer, J. H. and Schroeder, M. D., The Protection of Information in Computer Systems, 1975
- RFC 6749, The OAuth 2.0 Authorization Framework, October 2012
- Ethereum white paper, 2014
- Stellar Developers, Fees, resource limits and metering (accessed 2 November 2026)
- Stellar RPC, simulateTransaction (accessed 2 November 2026)
- Stellar Developers, Lumens (XLM) and base reserves (accessed 2 November 2026)
- SDK policy template
- custom-policy
- policy-wallet
- Stellar RPC API reference: sendTransaction
- Stellar RPC API reference: getTransaction
- DeFindex Vaults
- DeFindex Blend Autocompound Strategy
- Blend Lending Documentation
- Soroswap Router Contract Source
- ENS Endowment Investment Policy, EP6.46
- Lewis et al. 2020, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Hu et al. 2021, LoRA: Low-Rank Adaptation of Large Language Models
- Ouyang et al. 2022, Training language models to follow instructions with human feedback
- Rafailov et al. 2023, Direct Preference Optimization: Your Language Model is Secretly a Reward Model
- Guo et al. 2017, On Calibration of Modern Neural Networks
- Geifman and El-Yaniv 2017, Selective Classification for Deep Neural Networks
- Manidis and Roberts, The Commanding Heights
- Diogo Almeida — Introducing System One Models & Jev (TypeSafe, 2026)
- System One Models — decision and extraction models