Platform · Security, privacy & audit
Security that covers people, agents and every action
One3 is designed so that every person, Digital Employee and integration works inside tenant isolation, least-privilege access, risk-tiered approvals and an immutable audit trail.
Trust is built into the kernel, not added later
In One3, every change to business data goes through the Action Bus: a typed Action that is checked for entitlement, permission, policy, risk tier and budget, then executed and written to an immutable audit log. The same path applies whether a person, a Digital Employee, an API key or an external AI assistant asks for the change.
That single path is what makes the rest of this page possible. Approvals, separation of duties, step-up authentication, consent checks and kill switches all sit at one enforcement point that cannot be skipped from the UI or from a prompt.
Tenant isolation tiers
| Tier | How it works | Designed for |
|---|---|---|
| Pooled | Shared Postgres with tenant_id on every row, Row-Level Security, and per-tenant encryption keys for sensitive fields | SMBs and agency sub-accounts |
| Bridge | Dedicated schema or database on a shared cluster, with dedicated vector collections | Mid-market and regulated tenants |
| Silo | A dedicated cell (database, workers, optional GPU) in the chosen region | Enterprise, BFSI, government |
| Sovereign | One3 Box on-premise or air-gapped, with open-weight models | Defence, government and data-sovereign buyers |
Rented Digital Employees are isolated in two layers
Every rented agent has a shared template and a private tenant instance. No data or playbook from client A can reach client B.
Shared template
Role spec, skill and language packs, evals, persona policy and base prompts. It improves only from synthetic data, One3's own usage and opted-in, anonymised, aggregate signals.
Private tenant instance
Your knowledge scopes, memory, playbooks, adapters, traces, contacts, credentials and ROI records. They never leave your tenant.
Tenant-bound context
Context assembly may only reference the tenant's own stores, enforced with tenant-bound credentials, not prompt instructions.
Partitioned caches and adapters
Semantic, embedding and tool-result caches are tenant-partitioned. Per-tenant adapters are encrypted with tenant keys.
Canary-token audits
Unique synthetic "secret facts" are planted per tenant and scanned for in template outputs, shared adapters and caches. The pass criterion is zero detections.
Deletion certificate
At rental end, data is exported in an open format, then memory, adapters, caches and indexes are deleted and a certificate lists the stores purged.
Security architecture at a glance
| Area | Planned controls |
|---|---|
| Identity | OIDC/SAML SSO, MFA and passkeys, SCIM, agent identities with short-lived tokens, owner, purpose and expiry, service accounts |
| Authorisation | OpenFGA relationships with attribute conditions such as amount limits, time and data classification; least privilege for agents; per-Action risk tiers |
| Agent safety | Tainted-input tracking, tool allow-lists, spend and rate budgets, kill switches per agent, tenant and platform, sandboxed code execution, schema validation of outputs |
| Synthetic media | AI disclosure on every avatar and voice interaction, C2PA provenance on generated media, rights-registry checks before any real-person likeness or voice |
| Data | Encryption in transit and at rest, per-tenant envelope keys, field-level encryption for PII, DLP scanning, data-residency cells |
| App security | OWASP ASVS Level 2, dependency, SAST, container and secrets scanning, signed images, SBOMs |
| Audit | Immutable, hash-chained audit log, exportable to a SIEM; admin access with break-glass and approval |
| Resilience | Point-in-time recovery for Postgres, 3-2-1 backups and quarterly chaos drills |
Every Action declares how reversible it is
| Reversibility class | What the UI is designed to promise |
|---|---|
| Fully reversible | "Reverse" |
| Compensatable | "Compensate", for example with a credit note or a correction message |
| Externally irreversible | "Can't be reversed. Follow-up options available." |
| Legally irreversible | "Legally binding. Only formal correction processes apply." |
| Privacy-impact irreversible | "Disclosure can't be withdrawn. Incident process applies." |
Approvals follow risk and reversibility
Approval defaults combine the reversibility class with the risk tier R1–R4. R4 Actions always need human approval, and compensatable or externally irreversible R4 Actions also need a second factor. Legally irreversible R4 Actions need a named signatory, and privacy-impact Actions need owner or DPO review. One3 says "reverse or compensate", never "undo anything".
Privacy and DPDP-aware erasure
Right-to-erasure is designed to reach AI stores too. Regulatory points here are pointers, not legal advice; verify obligations with counsel.
- 1
Resolve the person
Find the party and every role row across apps, such as contact, candidate and employee, through the data ownership matrix.
- 2
Check blockers
Statutory retention such as payroll or tax invoices, legal holds and open disputes. Blocked fields are minimised or pseudonymised, with the reason recorded.
- 3
Delete or pseudonymise
Names, contact points, files, custom fields, activity payloads, vector chunks, agent memory, and avatar or voice assets.
- 4
Handle archives
Record the erasure in a ledger, then rewrite archives or destroy the party's data key (crypto-shredding), subject to legal review.
- 5
Rebuild derived data
Read models and caches are rebuilt; training lineage is checked and affected per-tenant adapters are scheduled for retraining.
- 6
Prove it
Evidence is stored as a privacy audit event and a completion notice is sent.
Audit and oversight
Every identity, access, subscription, mandate, consent and Action change is designed to leave evidence.
Hash-chained audit log
Append-only events with actor, tenant, before and after, reason, IP, device and auth assurance.
Replayable decisions
Any autonomous decision can be replayed with the context, model versions and tool results used at the time.
Three-party logging
For rented agents, logs record the vendor template version, the agency configuration version and the client mandate version.
Consented support access
One3 support never logs in as a customer by default. Access needs a ticket, admin consent, a visible banner and a full audit trail.
SIEM export
Admins can filter and export audit events, and Enterprise tenants can stream them to a SIEM.
Board AI oversight report
A quarterly report on autonomy, approvals, overrides, undo and incident counts, sourced from the audit log, not generated text.
Assurance levels for modules, connectors and templates
| Level | Meaning |
|---|---|
| Experimental | Built and passing CI, no production evidence. Not available to production tenants by default. |
| Sandbox verified | Works end-to-end on synthetic tenants, including failure paths, with isolation and reversibility tests |
| Partner verified | Proven with at least one real tenant under supervision |
| Production certified | Supported for general sale, with security review, a named owner and an update SLA |
Our claim rules
One3 names only certifications it actually holds. The plan sets a compliance path (DPDP Act and Rules from W1, ISO 27001 and SOC 2 Type I targeted for the end of Year 1, SOC 2 Type II in Year 2, ISO 42001 in Years 2–3), but none of these is claimed as held today. We do not use phrases such as "fully compliant" or "bank-grade" without substantiation. Nothing above Sandbox verified is sold as production-ready.
Trust in plan numbers
- tenant isolation tiers
- 4
- reversibility classes
- 5
- Action risk tiers, R0 to R4
- 5
- assurance levels for modules and connectors
- 4
- connector conformance behaviours tested
- 9
Questions about security and trust
Can a rented Digital Employee leak our data to another client?
The design prevents it in two layers: a shared template with no tenant data, and a private instance whose stores never leave your tenant. Cross-tenant leak suites and canary-token audits are planned to run continuously, with zero leaks as the pass criterion.
Is One3 SOC 2 or ISO 27001 certified?
Not today. ISO 27001 and SOC 2 Type I are targets on the compliance path for the end of Year 1, with SOC 2 Type II in Year 2. One3 will name only certifications it actually holds.
How does One3 handle DPDP requests?
Erasure is planned as a durable workflow that reaches every app plus vector indexes, caches, agent memory and training lineage, with statutory retention and legal holds respected. Treat this as a description of the mechanism and verify your obligations with counsel.
Can an AI agent make an irreversible change without approval?
R4 Actions always need human approval, often with a second factor. Externally, legally or privacy-irreversible Actions keep an approval gate regardless of the agent's autonomy level.
Can we run One3 in our own data centre?
The Sovereign tier is designed around One3 Box, an on-premise or air-gapped deployment with open-weight models, for buyers who need it.
Review One3's security design with your team
Talk to us about isolation, audit, privacy and how One3 plans to keep agents within your policies.