NIVQRA / AUTHORITY CASE 001
The agent can pay. But should it?
A worked case for bounded autonomous procurement.
NIVQRA thesis artwork · I.O.V editorial plate
The infrastructure for agentic commerce is arriving.
Agents can discover products, call APIs, negotiate with services and increasingly initiate transactions on behalf of people and organisations.
That creates a different problem.
The question is no longer simply:
Can the agent execute the transaction?
It becomes:
Who authorised this agent to make this transaction, for this purpose, with this counterparty, at this amount, at this moment?
That is an authority problem.
And access alone does not answer it.
The machine can act. That doesn’t mean it may.
- , then
- Mandate + policy, then
- Execution eligibility, then
- What the machine can reach.
- What the machine may do.
- Why it was allowed.
(opens the full-size image in a new tab)- Black panel: “The machine can act. That doesn’t mean it may.” — the case’s question stated as capability versus permission.
- Light panel: a concrete wall edge — authority as a boundary with real-world effects.
- Black panel: NIVQRA held between Human Authority above and Agent Execution below, with Policy and Context on either side.
- Light panel: a divided sphere on a vertical axis — access, authority and evidence as separate halves of one object.
- Black panel: Permit, Review, Hold, Deny, Escalate. These are editorial case outcomes, not core enum values; the core returns only ALLOW, DENY or REQUIRE_APPROVAL (see the technical legend).
- Light panel: a rock mass — durable, physical control for what comes next.
The mandate
Consider an autonomous procurement agent operating for a company.
Its job is straightforward:
Maintain sufficient compute capacity for the engineering organisation while avoiding unnecessary human intervention.
The company does not want an employee approving every €200 infrastructure purchase.
It also does not want an AI agent holding an unrestricted corporate payment credential.
So the human operator creates a mandate.
- Infrastructure procurement.
- Compute and data infrastructure.
- Existing approved suppliers.
- €750.
- €5,000.
- Approved European counterparties.
- Not permitted.
- Human approval required.
- Seven days.
The important object is not the payment credential.
It is the mandate.
The credential determines whether the agent can technically transact.
The mandate determines whether it is authorised to do so.
Four requests
During the day, the agent encounters four opportunities.
Request A: €420 compute purchase
Eligible for autonomous execution.
Eligible for execution · runtime ALLOW
Request B: €1,200 compute purchase
Human approval required.
Not eligible for execution · runtime REQUIRE_APPROVAL
Request C: €380 compute purchase from a new provider
Await counterparty approval.
Not eligible for execution · runtime REQUIRE_APPROVAL (new supplier)
Request D: €190/month recurring infrastructure subscription
Recurring commitments are outside the mandate.
Not eligible for execution · runtime DENY
Same agent.
Same access.
Different authority.
Request A
€420 of additional compute capacity from an approved provider.
Correct category.
Approved counterparty.
Inside the per-action ceiling.
Inside the daily budget.
Inside the active mandate.
The transaction becomes eligible for execution.
No human interaction is required.
Request B
€1,200 of additional capacity from the same approved provider.
Everything is valid except the amount.
The agent has access.
The supplier is legitimate.
The transaction may even be economically sensible.
But €1,200 exceeds the autonomous authority delegated to the agent.
The request routes to the named human authority.
The human can approve the exception, modify the mandate or reject the action.
The system does not need to decide whether the agent is trustworthy.
The boundary already decided what happens.
Request C
€380 from a new infrastructure provider offering substantially cheaper capacity.
The price is attractive.
The transaction is below the spending ceiling.
But the counterparty sits outside the mandate.
Cheap does not mean authorised.
The agent can surface the opportunity.
It cannot silently expand its own authority to capture it.
Request D
€190 per month for an automatically renewing infrastructure subscription.
The immediate amount is well inside the transaction ceiling.
But the mandate does not permit recurring commitments.
A small transaction can create a large obligation.
Authority therefore cannot be reduced to a single payment amount.
Purpose, duration, counterparty, commitment type and context matter.
What NIVQRA is governing
Notice what NIVQRA did not do.
It did not discover the supplier.
It did not decide which model to use.
It did not provide the corporate wallet.
It did not become the payment network.
It did not settle the transaction.
Those capabilities can belong to other systems.
NIVQRA governs the authority crossing between them.
The lifecycle becomes:
Identity → Mandate → Intent → Policy → Decision → Execution Eligibility → Effect → Evidence → Revocation
Execution can change.
The authority model should remain legible.
That distinction becomes more important as companies assemble agentic systems from multiple models, tools, protocols, wallets, payment providers and internal APIs.
A company may eventually have hundreds of agents operating across dozens of systems.
The organisation still needs one coherent answer to a basic question:
What is each machine actually allowed to do?
After the action
Authorization is only half the problem.
Once Request A executes, NIVQRA produces an Authority Evidence Record.
The record should make it possible to reconstruct:
- Who delegated authority.
- Which agent acted.
- What mandate was active.
- What the agent intended to do.
- Which policy was evaluated.
- Why the action was permitted.
- Which execution system produced the effect.
- What happened.
- Whether the authority remained active, was consumed, expired or was revoked.
A transaction log can tell us that something happened.
An authority record should tell us why the machine was entitled to make it happen.
That difference becomes important when an autonomous system touches money, infrastructure, customer data, contracts or production systems.
Revocation
Now suppose the company detects unusual activity from the procurement agent.
Traditional permission systems often create a coarse choice:
Leave the credential active.
Or shut the system down.
An authority layer allows a narrower response.
The infrastructure mandate can be revoked immediately.
The agent may remain operational.
Its other mandates may remain untouched.
Its underlying integrations do not necessarily need to disappear.
But this specific authority no longer exists.
The machine has not been disabled.
Its constitutional boundary has changed.
The bigger system
Agentic commerce is creating new infrastructure around machine identity, verified intent, authorization and transaction execution.
That work matters.
NIVQRA's thesis is that organisations will need another layer across those systems:
human authority expressed as machine-enforceable boundaries.
Payment protocols may execute transactions.
Agent frameworks may orchestrate workflows.
Identity systems may establish who or what is acting.
NIVQRA is being designed to answer the organisational question above them:
Under whose mandate may this action occur?
That is why NIVQRA is intentionally standards-neutral.
Any agent.
Any model.
Any execution rail.
One authority layer.
Payment rails move value.
Agent frameworks orchestrate actions.
Identity systems establish actors.
NIVQRA asks a different question:
Under whose authority is this machine allowed to act?
The full NIVQRA technical architecture.
Five layers across three planes. Select a layer to read its components and functions, or show all five as text. Selecting an execution path marks the layers it crosses.
Five layers · canonical reference and target design · not a statement of production availability
- NIVQRA determines whether an intended action is authorised.
- Agents, APIs, payment systems, services and other infrastructure perform the actual action.
- The system records why the action was authorised and what happened afterward.
Execution paths — select one to mark the layers it crosses
No path selected.
Policy compiler
Target architecture
Human rules → deterministic, machine-readable policy.
Authorization engine
Canonical model
Deterministic evaluation at the /v0/authorize boundary of Identity + Mandate + Intent + Organisation policy + Context. The same governed request produces the same outcome.
Decision point
Canonical model
Workflow outcomes PERMIT, REVIEW, HOLD, DENY, ESCALATE. At runtime these resolve to ALLOW, DENY or REQUIRE_APPROVAL only — see the legend.
Approval router
Target architecture
Sends genuine exceptions to the correct human authority. Approval binds to the exact intent and is followed by reauthorization before any eligibility. The goal is not human approval for every action; it is governed autonomy.
Human / organisation authority
Canonical model
The accountable principal who owns authority and delegates it. Drafting or reviewing a mandate does not activate it.
- Authority ownership
- Delegated principals
Identity registry
Canonical model
Establishes who is acting. Identity is necessary; it is not permission.
- Human identity
- Organisation identity
- Agent identity
Mandate registry
Canonical model
Versioned, machine-readable Machine Mandates.
- Mandate scope
- Purpose
- Limits
- Expiry
- Geography
- Counterparties
- Recurrence
- Revocation state
Agent / model runtime
Canonical model
Any agent, any model. NIVQRA remains model-neutral and does not choose or host the model.
Intent envelope
Canonical model
Normalises a proposed action into a policy-readable object.
- Actor
- Requested action
- Target resource
- Amount
- Counterparty
- Purpose
- Context
Context & risk signals
Target architecture
Signals that may inform policy. Illustrative inputs, not implemented feeds.
- Spend velocity
- Anomaly state
- Jurisdiction
- Supplier state
- Session / device context
- Operational environment
Policy compiler
Target architecture
Human rules → deterministic, machine-readable policy.
Authorization engine
Canonical model
Deterministic evaluation at the /v0/authorize boundary of Identity + Mandate + Intent + Organisation policy + Context. The same governed request produces the same outcome.
Decision point
Canonical model
Workflow outcomes PERMIT, REVIEW, HOLD, DENY, ESCALATE. At runtime these resolve to ALLOW, DENY or REQUIRE_APPROVAL only — see the legend.
Approval router
Target architecture
Sends genuine exceptions to the correct human authority. Approval binds to the exact intent and is followed by reauthorization before any eligibility. The goal is not human approval for every action; it is governed autonomy.
Execution gateway
Canonical model
The enforcement choke point. Only authorised intents become eligible for downstream execution; eligibility is claimed once per intent. A credential, payment offer or provider availability is never authority.
Capability router
Target architecture
Maps an authorised action to the appropriate execution adapter.
Protocol adapters
Target architecture
Provider-specific logic lives only here; the core contains none. Systems or standards adapters may eventually connect to — examples, not live integrations or partnerships:
- MCP
- A2A
- AP2
- x402
- Wallets
- Payment providers
- Cloud systems
- Internal APIs
- SaaS systems
Execution systems
Canonical model
External systems perform the effect and move value. NIVQRA does not custody funds or keys. Authorization is not proof of execution; execution is not proof of business truth.
Authority Evidence Record
Canonical model
Produced for every attempt, whether or not execution occurs. States stay distinct: submitted, confirmed, failed, unknown. It answers:
- Who delegated authority?
- Which agent acted?
- Which mandate applied?
- What did the agent intend?
- Which policy was evaluated?
- What decision was made?
- Why?
- Which execution system created the effect?
- What actually happened?
- Is the mandate still active, consumed, expired or revoked?
Audit & observability
Canonical model
Unknown outcomes are reconciled read-only — never by automatically retrying the effect. Evidence can be exported as a detached simulation receipt and read as a read-only Authority Graph: observation surfaces, never a grant of execution permission.
Revocation service
Canonical model
First-class. A mandate can be revoked, narrowed, expired or consumed without necessarily destroying the underlying credential or shutting down the whole agent. Revocation blocks future eligibility; it does not reverse an external effect already completed, and is itself recorded.
Governance console + SDK
Target architecture
Human authority console and developer SDK. Planned after core behaviour is real; not presented here as available.
Identity → Mandate → Intent → Policy → Decision → Execution Eligibility → Effect → Evidence → Revocation
From approval to autonomy
The objective is not to put a human approval screen in front of every machine action.
That would destroy much of the value of autonomous systems.
The objective is the opposite.
Define the boundary well enough that machines can operate independently inside it.
Human attention moves toward exceptions.
Routine actions disappear into governed autonomy.
NIVQRA describes that progression as:
OBSERVE
The agent proposes.
APPROVE
The agent acts after explicit human approval.
BOUND
The agent acts autonomously inside declared limits.
AUTONOMIZE
The agent operates continuously inside a mandate, producing evidence and remaining revocable.
Autonomy is therefore not the absence of control.
It is what becomes possible when control is explicit enough.
The thesis
The next generation of software will not merely answer people.
It will act for them.
And when software can spend, purchase, deploy, negotiate, publish, provision and transact, organisations will need more than access control.
They will need a machine-readable constitution for delegated authority.
Access determines what the machine can reach.
Authority determines what the machine may do.
That is the layer NIVQRA is being built to explore.
AI may propose.
NIVQRA enforces.
Humans define the boundary.
Status
NIVQRA remains I.O.V Lab product work. This Authority Case illustrates the intended control model rather than a claim of a live customer deployment. The current environment demonstrates the authority lifecycle, while external protocol and payment-rail integrations should only be described as live once technically implemented and verified.
The current V0.1 environment demonstrates the authority lifecycle with simulated execution surfaces.
Edition prepared 24 September 2026 · IOV/AC-001 · edition 1.0 · not legal, regulatory, security or investment advice.