Trust · security

Written for the person who has to sign off

Not a badge wall. What the controls actually are, where they are enforced, what is tested and how often, and the two architectural decisions a reviewer should push on.

Request the security pack

SOC 2 report under NDA, DPA, sub-processors, penetration test summary, and architecture overview.

1 / 3
Isolation enforced in the data layerAnnual penetration testingRestore tested quarterly

Controls

Six areas, with where each is enforced.

Tenant isolation

Every query carries a tenant scope and the data layer rejects an unscoped read or write rather than trusting callers to filter. This is enforced below the API, so it holds for every endpoint including exports and the portal.

Encryption

TLS 1.3 in transit. AES-256 at rest across databases, object storage, and backups. Keys managed in a dedicated KMS with rotation and separated duties.

Access control

Role-based permissions with least privilege, SSO via SAML or OIDC and SCIM provisioning on Enterprise, and mandatory MFA for administrative roles.

Audit logging

Human actions, agent actions, and privileged administrative changes in one append-only schema with content hashes, exportable to your SIEM.

Backups & recovery

Continuous backup with point-in-time recovery, five-minute RPO and four-hour RTO, restore tested quarterly with results in the security pack.

Secure development

Peer review on every change, dependency and secret scanning in CI, staged environments with no production data, and annual third-party penetration testing.

The two things worth pushing on

Most security questionnaires spend their length on controls that are table stakes and skip the two architectural decisions that actually determine blast radius. If you only have time for two questions, ask these.

One: where is tenant isolation enforced?

The common answer is "in the application layer" — every query includes a tenant filter because the developers remembered to add one. That works until somebody writes an endpoint that forgets, which is a class of bug that has produced most of the cross-tenant incidents in this industry.

Ours is enforced in the data access layer: a query without a tenant scope is rejected rather than executed, and there is no code path that can express one. Row-level security in Postgres sits underneath that as defence in depth. The practical test — which you should apply to any vendor — is whether a developer could write an unscoped query and have it run. Here the answer is no, because it fails at the layer below them.

Ask whether a developer could write an unscoped query and have it succeed. If the answer is "they wouldn’t," that is a process control, not an architectural one.

Two: what can automation do without a human?

This is the question unique to an AI-native system and the one most security reviews do not yet ask. Agents in this platform operate under an explicit authority model with five levels, enforced as middleware by a deterministic policy engine the agent cannot address or argue with.

Four actions are absent from the permission model entirely rather than defaulted off: releasing funds, closing or reopening a period, writing to the general ledger directly, and modifying permissions. There is no configuration that produces them, which means the blast radius of a compromised or misbehaving agent is bounded by construction rather than by policy.

Agent access, specifically

  • Scoped like a user. An agent reads only what its role permits within its tenant, and its reads are logged identically to a person’s.
  • No credential inheritance. Agents do not act as the user who triggered them. They hold their own identity with their own permissions, which is what makes the audit trail meaningful.
  • Model providers see the minimum. Context sent for inference is scoped to the task and governed by agreements prohibiting training on it. Prompt context is stored as references to your records rather than copied blobs wherever possible.
  • Instantly revocable. Authority can be dropped globally in one action, putting every agent back to draft without losing in-flight work.
Responsible disclosure

We operate a disclosure programme and will not pursue researchers acting in good faith. Report through contact with "security" in the subject; we acknowledge within one business day and publish an advisory once a fix is deployed.

Questions

What reviewers ask.

Do you support SSO and SCIM?
SAML and OIDC single sign-on plus SCIM provisioning on Enterprise. MFA is mandatory for administrative roles on every tier, not optional.
Who at erp.io can see our data?
A small number of engineers under break-glass access that is time-bound, requires a second approver, and is logged and reported to you. Routine support does not include production data access.
Do you run penetration tests?
Annually by an independent firm, with a summary in the security pack. Findings are remediated on a severity-based timeline that is also published in the pack.
What is your sub-processor list?
Published and versioned, with notice before additions. It includes hosting, model providers, email, and payment infrastructure.
How do you handle a breach?
Notification without undue delay and within contractual timelines, a written incident report, and a published post-incident review for anything customer-affecting. The notification commitment is in the DPA rather than left to discretion.
Can we do our own penetration test?
Yes, against a staging environment with scope agreed in advance. Several Enterprise customers have, and we will share the remediation status of anything found.

Send this to your reviewer.

The pack answers most questionnaires directly, and we will take questions from your security team without a salesperson on the call.