Security & data handling
Written for security, procurement and compliance reviewers. It sets out how sign-in works, what the audit log records, what data this environment holds, and — line by line — which parts of the product are working software and which parts are simulated for the pilot.
Sandbox only. No custody, no customer funds and no live payment execution.
Authentication
Access is account-based. A visitor can sign in with an email address and password, or with Google. Sign-in is handled by the managed authentication provider behind the product; the application never stores or sees a password, and sessions are issued and refreshed by that provider rather than by application code.
Every product screen — overview, agents, policies, requests, audit trail and the guided demo — sits behind an authenticated route. An unauthenticated visitor is redirected to the sign-in page. The public pages are the landing page, this page and the how-it-works memorandum.
- Email and password, or Google sign-in
- Passwords are never handled or stored by application code
- All product screens require an authenticated session
- A shared demonstration account exists so reviewers can see the pilot without creating an account
The demonstration account is intentionally shared and contains only sample pilot data. Treat anything entered while using it as visible to other reviewers.
Authorisation and data isolation
Data is scoped to the organisation a user belongs to. Agents, mandates, policy rules, purchase requests, transactions and audit events are all attached to an organisation, and access rules are enforced in the database rather than only in the interface — a user cannot read another organisation's records by calling the API directly.
Actions that change state — creating an agent, editing a mandate, approving or refusing a request, running or resetting a demonstration case — run server-side against the caller's own session, so the identity recorded on the resulting audit event is the identity that was authenticated.
Audit logging
Each purchase request produces a chain of separate, timestamped events rather than a single mutable status field: the principal instruction, the agent's intent, the deterministic policy decision, the human decision where one was required, the simulated settlement and the resulting record. Each event carries its actor and the reason for the outcome.
The trail is append-only in behaviour. The interface provides no way to edit or delete an event once it is written, and refusals are recorded exactly like approvals — a blocked request leaves as much evidence as an approved one. The full trail, and the request docket, export to CSV for filing alongside your own records.
- One event per stage, with actor, reason and timestamp
- Policy decisions record the specific rule that produced the outcome
- Approvals record the named approver, the decision and the rationale
- No edit or delete path in the interface
- CSV export of both the request docket and the audit trail
Reset restores the canonical demonstration state for the three pilot cases. It is a demonstration control, not an editing tool — it is disclosed here because it is the one action that changes what a later reviewer sees.
Deterministic decisions
No language model decides whether a purchase is allowed. The policy engine evaluates budget remaining, per-purchase ceiling, permitted category, permitted vendor and prohibited list in a fixed order, and the same request always produces the same outcome. A model may draft or initiate a request; it has no influence on the decision and no path around the mandate.
This matters for review: the control can be tested by replaying inputs, and a refusal always names what was violated instead of returning a generic error.
Authority safety model
AI may propose. NIVQRA enforces. Humans define the boundary.
Ten principles govern how delegated authority behaves in this product. They are the contract a reviewer can hold the system to.
Deterministic enforcement
The same request always produces the same outcome. No model decides.
Least authority
An agent holds the smallest scope that lets it do its job, and nothing more.
Explicit mandate scope
Categories, counterparties and purposes are written down, not inferred.
Hard limits
Per-action ceilings and period budgets cannot be exceeded by any path.
Counterparty/resource controls
New or non-approved counterparties do not clear automatically.
Idempotent execution
A single approved intent settles once; repeats do not multiply effect.
Human exception routing
Anything outside the mandate goes to a named person, not to a default yes.
Full attribution
Every action names the instructing principal, the agent and the deciding human.
Evidence exports
The complete chain exports to CSV for filing with your own records.
Immediate revocation
Authority can be withdrawn at once, and the withdrawal is itself recorded.
Payment execution remains simulated in this environment; the principles above describe how authority is enforced, not that funds move.
Data in this environment
The pilot environment contains simulated operational data — three agents, their mandates, the policy rules, the canonical demonstration cases and the resulting requests, transactions and audit events. No production data, customer data or real vendor relationship is present.
The only genuine personal data the environment can collect is what a visitor submits: the contact details in the pilot access form, and the email address on an account created for sign-in. Those are used to respond to the request and to operate the account, and nothing else. If you would like your submission removed, ask the pilot contact and it will be deleted.
Simulated versus not simulated
The line below is the honest boundary of this MVP. Everything marked as working software runs as described; everything marked simulated is deliberately modelled so the control model can be evaluated without moving money or onboarding a payment provider.
What this pilot does not claim
It has not been independently audited, certified or penetration-tested, and it carries no compliance attestation. It is not production-hardened, and it has no live payment execution, no vendor integrations and no enterprise access management. Those are the questions the pilot exists to surface — the control model is the part being validated here.
Reporting a concern
If you find a security issue or have a data-handling question, use the pilot access form and mark it as a security enquiry. Please do not test against the environment destructively; it is a shared demonstration and other reviewers may be mid-session.