Governance and security
AI that can act, inside limits it cannot move.
Security is enforced at several choke points: database isolation, identity and role checks, capability grants, action risk, approval policy, spending policy, connector execution, release gates and privacy routing. No single prompt is expected to provide all of those controls.
Autonomy
Four tiers, decided in code.
The action registry assigns every built-in action a default tier. A workspace policy can make an action stricter, but cannot lower the mandatory approval floor of a T3 action.
- T0Runs immediatelyNo person involved. For low-risk, trusted, reversible actions.
- T1Asynchronous approvalCreates an approval with a 24-hour window. For medium-risk actions.
- T2Blocking approvalExecution waits until you decide. For high-risk actions.
- T3Never autonomousAlways refused for autonomous execution. For critical actions.
Approval gates
Consequential actions wait for a person.
- Any action rated Medium risk or above requires explicit approval before it executes
- Default policies keep contract, payment, code deploy, code commit and content delete actions behind approval
- Auto-approve rules are owner-only, and Critical-risk actions can never be set to auto-approve
- Per-action daily spending ceilings force an action into approval instead of allowing silent overspend
- An owner-only kill switch pauses every mission and pending action until it is turned off
- The system never changes an agent’s prompt, budget, model or permissions without an approved proposal
Audit
A record the application cannot rewrite.
Every execution state transition is written with the acting agent or user: submitted, gated, approved, rejected, started, succeeded, failed, rolled back, cancelled. The application’s database role cannot edit or delete audit-log rows.
Model calls are recorded with tokens and estimated cost, so every action can be traced to who asked, who approved and what it cost.
Data isolation
Tenant isolation is a database concern.
Tenant-scoped data is protected by PostgreSQL row-level security, with FORCE RLS on tenant tables and request-scoped tenant context, plus explicit service-layer scoping on sensitive queries. An automated check fails the build if a tenant table is added without row-level security.
Encrypted at rest
AI provider keys and connector credentials are encrypted. Keys can be stored per tenant and rotated in the application without editing the environment file.
Accounts and sessions
Passwords use Argon2id. Sessions end on logout or password change, and password reset links work once.
Release gates
CI scans source, dependencies, secrets and container configuration. A critical vulnerability or a secret leak can block publish or deploy, and a fix counts only after the scanner reruns.
Roles and scopes
Each kind of user gets a different surface.
- Owner
- Everything, including the high-impact operations: destructive deletes, security containment, secret rotation, licensing and many financial changes, auto-approve policies and Business Twin approvals.
- Operator
- Runs the organisation day to day and can propose changes, but cannot change what auto-approves itself.
- Observer
- Read-only, enforced centrally.
- Venture staff
- A separate identity scope accepted only by the operational routes built for staff work, with role definitions for record types, stages, pages, actions and fields. Membership is re-read on every request.
- Customer portal
- Only explicitly enabled components and customer-visible fields. Record ownership is re-derived on every request rather than trusted from a link.
- Provider staff
- On a provider installation only: a separate scope limited to the Fleet page and the customers the owner assigns, re-checked on every request.
Privacy mode
You decide what reaches an AI provider.
AI-analysis consent is owner-controlled and can be revoked. Identifiers are masked before relevant document content leaves the platform. In local-only mode the work must run on a private local model through Ollama, or it fails closed; it never falls back to a cloud model.
Readiness check
Configured is not the same as proven.
The Readiness Check combines system health, AI provider connectivity, security assurance, tenant isolation, capabilities, notifications and backups into one report. It exercises the approval path with a real action that has no side effect.
- VERIFIEDA real check ran and passed just now.
- CONFIGURED, NOT VERIFIEDSet up, but not proven to work.
- NOT CONFIGUREDNot set up yet.
- FAILEDA real check ran and failed.
- NOT APPLICABLEDoes not apply to this installation.
Boundaries
What these controls mean, and what they do not.
- Self-hosted
- The application and its primary data stores run in infrastructure you control. A connected cloud AI provider, email service, payment gateway or SaaS connector still receives the data that integration needs.
- Governed autonomy
- Low-risk work can run automatically when policy permits, and higher-risk actions go through approval or are blocked. It does not mean every action needs a click, and it does not mean an agent can bypass a control because it was asked persuasively.
- Masking
- Masking covers categories such as ID numbers, IBANs, card numbers, phone numbers, email addresses and secrets. It does not reliably detect every national ID format, personal names or free-text addresses.
- Certifications
- ErezAgent does not claim third-party security certifications. Evaluate the controls on this page in your own pilot, under your own security constraints.
Next step
Test the controls on a real process.
A useful pilot includes at least one action that runs automatically and one that must wait for approval, so the governance model is exercised rather than watched.
Paid evaluation and guided deployment: talk to us. See the plans.