Security

You are pointing us at the agents that run your business.

Here is what Arceo can see, where it runs, what is built in, and, at the bottom, what we have not done yet.

What Arceo can see

The whole product is built around answering a question before deployment, which means it needs far less access than tools that sit in the runtime path.

Discovery is read-only

Arceo reads your agent's tool definitions and source to work out what it can call. Producing the report needs no write access to any of your systems, and Arceo never asks for one.

No production credentials required

Mapping capabilities and forecasting cost work from the agent's own definition. You do not hand over live keys to your payment processor, CRM, or database to get a report.

Runtime enforcement is opt-in and separate

If you later want Arceo to actually block actions, that is a deliberate second step you configure. Nothing about the forecast requires it.

Where Arceo runs

Pilots run inside your own infrastructure. Arceo ships as a single container that you deploy to your cloud account, against a PostgreSQL database you control. You supply the TLS termination, the database, and your own model API key.

In that configuration your agent definitions, traces, and cost data stay within your network boundary. The only outbound calls are the ones you configure: to your model provider for risk classification, and to your own alerting webhook if you set one.

Controls built into the product

Tenant isolation

PostgreSQL row-level security, ENABLEd and FORCEd on every organisation-scoped table. Enforced by the database itself, beneath the application code.

Encryption at rest

Envelope encryption for sensitive columns, including captured prompts and responses, behind a deployment-level switch with a documented key-rotation path.

Tamper-evident audit log

Every privileged action is written to a hash-chained audit log, so a deleted or edited entry breaks the chain and is detectable.

Session revocation

Tokens carry a version, so disabling a user or rotating an organisation's secret invalidates issued sessions immediately.

Transport hardening

HSTS, a restrictive Content-Security-Policy, frame-ancestors none, and nosniff are set on responses.

Scoped API keys

Machine access uses hashed, scoped, individually revocable keys.

Independent review

The backend has been through a full independent security audit covering authentication, tenant isolation, injection, cryptography, dependencies, logging, and cost abuse, endpoint by endpoint, across the whole service.

Headline result

Zero critical findings

No SQL injection, no reachable code execution, and no cross-tenant read leak at the application layer. Findings that were raised are tracked in a phased remediation roadmap with per-item validation.

We share the full report, the finding-by-finding detail, and current remediation status under NDA with pilot customers. Ask for it. We would rather you read it than take the summary on trust.

What we have not done yet

The honest version

Any vendor can list controls. The more useful question is what they leave out, so here is ours.

We are not SOC 2 certified.

The code-side control work (audit logging, transport hardening, encryption, backups) is underway, but no auditor has attested to it yet.

There is no multi-tenant hosted offering.

Every pilot today is a single-tenant deployment in the customer's own environment. That is a deliberate choice while the shared-tenancy path finishes hardening.

We are early.

Arceo is pre-general-availability and working with its first design partners. You would be evaluating a working product alongside its first design partners.

Ask us anything about this