The limits are not a setting the agent can change.
Anything an agent reads, a web page, a document, a message from another agent, can try to convince it to spend. That is why the decision does not belong to the agent.
Six properties
Spending rules are enforced on our side.
Checked before any money moves, on infrastructure the agent does not control. The check sits in the path rather than beside it, so a request that fails never reaches the point where money would move.
Prevents: An agent being talked into a payment it should not make.
An agent cannot raise its own limits.
Only you can change what an agent may do. An agent asking to widen its own budget is refused every time, by architecture rather than by policy.
Prevents: A compromised agent quietly giving itself more room.
Altering the record is detectable.
Entries are written once, never updated in place, and each is chained to the one before it. Changing a past entry breaks the chain.
Prevents: A changed record passing as the original.
Amounts are exact.
Money is handled in whole units throughout, and balances are derived from the record rather than trusted from a running total.
Prevents: Rounding drift that nothing reconciles.
Results are data, never instructions.
Operity returns what one agent sends another as a typed value, not as text to obey. What your code does with it is yours.
Prevents: Operity acting on content that arrived inside a result. It cannot stop your agent from doing so.
Authority only narrows.
When work is passed on, the budget and permissions available downstream are a subset of the original. Delegation cannot widen what was granted.
Prevents: Permissions growing as work is subcontracted onward.
A convincing ask and a nonsense one get the same answer
The check does not read for tone, authority or urgency. It compares what was asked against what you already allowed. An instruction crafted to sound official fares exactly as well as gibberish.
Everything an agent's model can influence arrives as a request. Everything that protects money sits on the other side of that line.
What Operity does not do
A control described precisely is worth more than one described generously.
It does not judge whether a payment is a good idea.
A transfer satisfying every rule you configured is allowed, even if it is a mistake, and even if someone engineered the situation so it would fit. We enforce your rules. Deciding they are narrow enough is yours.
It cannot stop your agent obeying what it reads.
We return results as data. Whether your code then puts that data into a prompt happens inside your system.
It does not secure your agent or its credentials.
The machine it runs on, the key it holds, and who can reach it are outside our boundary. A stolen agent credential can spend up to that agent's limits.
It is not fraud detection.
No model scores transactions for suspicion. The system is deterministic: rules in, allow or refuse out.
It does not govern spending outside itself.
Model tokens, cloud bills and anything paid by another route are invisible to us.
These describe how the system is built. They are not a certification, an audit or a compliance claim, and we will not describe them as one.