Security and controls

Written for the person who signs off the pilot

An agent that reads public content and can spend money or contact people creates specific risks. These are the controls the product is built around, and the gates it must pass before any live mandate is enabled.

The model proposes, policy decides

  • Permissions live in application code. The same policy service governs chat, voice, scheduled tasks and imported automation.
  • Each approval binds an authenticated approver to a particular action: property or case, amount including tax, supplier or recipient, document version, terms, expiry and maximum uses.
  • A bare yes is insufficient when several decisions are outstanding. Changes to price, recipient, scope or documents invalidate the prior approval.
  • Authority and current external state are rechecked immediately before execution. Proposed, authorised, submitted, confirmed and failed states are stored separately.
  • A sent API request is not proof of completion. Uncertain financial or booking actions are reconciled, never retried blindly.

Evidence and answer quality

  • Structured records hold prices, status and amounts; documents hold provenance, clauses and context. Only evidence visible to the caller's role is retrieved.
  • Service charges are tied to an accounting year and a cost basis. Ground rent distinguishes the current amount from future review terms.
  • A building-safety answer never turns an absent report into a claim that a building is safe. Floor-plan answers keep their units and treat a drawing as a drawing.
  • When an answer cannot be supported the agent says so, creates a task for the missing information and logs what evidence it did have.
  • Memory is controlled data. A landlord can set a standing preference; a contractor's email cannot set a spending limit.

Security and operational reliability

  • Websites, messages, PDFs, portal data and quotes are untrusted content: evidence, never new operating instructions.
  • The public assistant is separated from privileged client approvals and internal administration.
  • Organisation and property access is enforced at the database and tool layers, including retrieval and caches.
  • Scoped service credentials and per-customer connectors; secrets stay out of prompts and logs.
  • Approval links bind to an authenticated person and a precise action; changing bank or recipient details needs stronger verification.
  • Action budgets, tool-call limits, deadlines and maximum retries, with loop and duplicate detection.
  • Inbox and outbox events, idempotency keys, unique constraints and provider reconciliation throughout.
  • A tamper-evident action history alongside privacy retention, restricted access and justified legal holds.
  • The global pause stops new external actions while provider events are still received and reconciled.

Rules and launch gates

  • Four nation rule packs, each rule with its legal source, effective date, applicability, permitted action, test scenarios and named reviewer. The model can explain a rule; it cannot change one.
  • Before live operation: the responsible operating entity, agent role, AML and sanctions responsibilities, redress, insurance, client-money arrangements and data-controller or processor roles are decided and signed off.
  • Consequential decisions about applicants carry explanations, meaningful human review and a contest route.
  • Release gates: zero cross-organisation disclosure, unauthorised external writes or duplicate charges in the test suite; every outward assertion traceable to evidence or labelled unresolved; every money, publication and booking action with an authority record and a confirmed or visibly unresolved result.

Logging captures decisions, evidence references, permission results and external receipts. It does not require storing private model reasoning. Customer-visible explanations state the relevant facts and authority plainly. A release test gate with zero cross-organisation disclosure is a test gate, not a claim of zero real-world risk.