Skip to content

Security

Your cloud, your approvals, and a record of every step.

Everything runs single-tenant in your own AWS account, or in a dedicated one we run for you. Our agents read your systems live, nothing posts to your ledger until a person with the authority approves it, and every change people make and every step agents take is logged.

Book a working sessionSecurity FAQ
Illustration of a customer's deployment, in their AWS account or a dedicated one we run for them: the application, database, credentials and code sandbox inside it, and what crosses its boundary: sign-in coming in; model calls, reads from connected systems, ERP writes held for approval and requests to the public web going out.
Your deploymentCustomer AWS / Dedicated AWSeu-west-1

Private network

  • Empty Spaces

    Single-tenant

  • Database

    Encrypted

  • Credentials

    Sealed separately

  • Code sandbox

    Isolated

Crosses the boundary

  • Sign-inYour identity provider
  • Model callsThe provider you choose
  • System readsThrough each system's API
  • ERP writesOnly once approved
  • Public webNo route to your private network

Security at a glance

The short version for a first read. Each line is covered in full further down.

Deployment
Your AWS account, or one we run for you
Tenancy
Single-tenant
Region
You choose
Identity
SSO with SAML or OIDC
Access
Custom roles
ERP writes
Human approval
Credentials
Encrypted, never shown to models
Audit
People and agents
Compliance
SOC 2 Type I and Type II

Deployment

It runs in your cloud, or in one we run for you alone.

Every customer gets their own deployment, by default in their own AWS account. If you'd rather not operate it, we run the same deployment for you in a dedicated AWS account. Either way, your data, files and compute are isolated from every other customer.

  • Your AWS account

    By default the infrastructure is applied in your account, and the record of how it is configured is kept there too. Hosted for you, it gets an account of its own.

  • Single-tenant

    Your database, file storage and compute serve your company alone. Departments get their own organisations inside it, and every record belongs to exactly one.

  • Your region

    Deploy in the AWS region your data-residency rules call for.

  • Private network

    The application, database and cache sit in private subnets, and the database and cache accept connections from the application only.

What crosses the boundary

  • AI provider

    Prompts and the context they need, sent to the AI provider you configure, which can be Amazon Bedrock in your own account.

  • Connected systems

    API requests to the systems you connect, such as your ERP, bank feeds and CRM. ERP writes wait for a person's approval.

  • Public web

    Pages an agent reads and calls made by code it runs in the sandbox. Neither has a route into your private network, and page reading can be switched off for your deployment.

  • Error reporting

    Off by default, and sent only if you switch it on.

We run no control plane and no shared service that holds your data, and traces stay in your database. Your deployment pulls our software from our registry, a request that carries none of your data, and we apply updates through a role you grant in your account.

Approvals

Nothing posts to your ledger until a person approves it.

Our agents prepare the work. The people with authority decide. Approval is tied to the exact entry, so what gets posted is what was actually approved.

  • Bound to the exact entry

    An ERP write runs only against a stored approval of its exact contents. If the payload changes, the approval no longer applies.

  • Used once

    Each approval covers one write. Running the action again needs another approval.

  • Separation of duties

    The person who requested the write can't approve it. Approvers need approval rights or the Controller role.

  • Read-only connections

    A connection set to read only can't be used to write, whatever an agent asks.

  • Other outbound actions

    CRM updates, Slack messages and mailbox changes follow the policy set for each agent. They ask for approval by default, and you decide which may run on their own.

Illustration of an approval request: an agent's purchase invoice posting to Business Central, held until a Controller approves it.
Awaiting approvalbusiness_central_post_document

Post purchase invoice

Halden LogisticsPI-10518$18,240.00
Requested by
Omar Haddad, through the AP Agent · 10:58
Approver
Controller
Payload hash
sha256:4f9a…c21e

The requester can't approve this write. Any change to it invalidates this approval.

Access

The right people, with exactly the access they need.

Sign-in goes through your identity provider, and roles are defined permission by permission.

  • Single sign-on

    SAML or OIDC, one per deployment, with Okta, Microsoft Entra ID, Google or Auth0. Multi-factor rules stay with your identity provider.

  • Custom roles

    Build roles from fine-grained permissions on each resource and action. There are no fixed tiers to fit into.

  • No privilege escalation

    Nobody can grant a permission they don't hold themselves, so delegation never widens access.

  • Session limits

    With SAML, a session token lasts an hour and every session ends within seven days. With OIDC, sessions follow your identity provider. API keys are stored only as hashes.

Data protection

Encrypted, and out of the AI's reach.

Your data is encrypted wherever it is stored. System credentials get a further layer of protection, and agents never receive them.

  • Encrypted at rest

    The database, file storage and sandbox disks are all encrypted.

  • Encrypted in transit

    Every connection to the application uses TLS 1.2 or higher, and plain HTTP is redirected.

  • Credentials sealed separately

    System credentials are encrypted again with AES-256-GCM, under a key generated for your deployment and kept in AWS Secrets Manager.

  • Credentials never reach the model

    They are decrypted on the server and added to a request as it is made, outside the model's context, so no agent and no code it runs ever receives one.

  • Masked in logs

    Known credential patterns are masked before anything is written to a log or a trace.

  • Backed up

    Automated database backups are kept for 14 days, and the database is protected against deletion. File storage keeps earlier versions for 30 days.

AI governance

AI you govern like the rest of your infrastructure.

Which models run, what they cost, what code they execute and what instructions they received are all controls you set and records you keep.

Illustration: three AI controls. A model policy that allows Claude Sonnet and GPT and blocks every other model; the code sandbox, with no credentials, no route into the private network and a temporary lifetime; and a trace of a run, a model call and two tool calls, completed.
  1. 01

    Your model keys

    Use your own provider accounts and keys: Anthropic, OpenAI, Google, Amazon Bedrock, DeepInfra, OpenRouter or any OpenAI-compatible endpoint.

  2. 02

    Approved models only

    Choose which providers and models each access group may use. A model not on the list is refused.

  3. 03

    Spend caps

    Set daily and monthly limits per access group. Once one is reached, its agents stop running.

  4. 04

    Isolated code execution

    Code an agent writes runs in an isolated, temporary container, with no credentials and no route into your private network.

  5. 05

    Every call traced

    Model calls and tool calls appear in the agent's execution trace, in the order it made them.

  6. 06

    Versioned instructions

    Every version of an agent's instructions is kept, so you can see what it was told when it did the work.

See the AI Gateway

Audit

A record of who did what, people and agents alike.

The questions an auditor asks, who had access, what changed and who approved it, have answers in the record.

  • Every change people make

    • Sign-ins
    • Failed logins
    • Role changes
    • Permission changes
    • Credential changes
    • Integration changes
    • Agent changes

    Each with who made it and when, in the activity log.

  • Every step agents take

    • Agent runs
    • Model calls
    • Tool calls
    • ERP writes

    Runs, model calls and tool calls are traced, and every ERP write is logged with the approval behind it.

  • Approvals you can reconstruct

    • Exact payload
    • Requester
    • Approver
    • Agent run

    Each approval keeps all four, and the posting it allowed is logged as its own event.

  • Kept in your database

    By default, activity is kept for a year and security events for two, and traces for 30 days. Read it in the app, or query it through the API with a service account.

Illustration of an activity log: a sign-in through Okta, a role change, a credential rotation, an ERP write requested by Omar Haddad and approved by Sara Malik, the AP Agent's posting of it, and a failed sign-in.
Activity logLast 24 hours
  1. 09:12
    Layla Hassanauth.login.succeeded

    Through Okta

  2. 09:14
    Layla Hassanrole.grants_added

    Close reviewer · 2 permissions added

  3. 10:02
    Omar Haddadintegration.credentials.rotated

    Business Central

  4. 11:05
    Sara Malikerp.write.resolved

    PI-10518 · $18,240.00 · requested by Omar Haddad

  5. 11:05
    AP Agenterp.document.posted

    PI-10518 · approved by Sara Malik

  6. 11:48
    Unknownauth.login.failed

    3 attempts

Kept 365 days, security events 730

FAQ

The questions security teams ask first.

A starting point for finance, IT, security and procurement. Anything not here, bring to the first call.

  • Where does our data live?

    By default, in your own AWS account, in the region you choose. If you'd rather not run it yourself, we run the same single-tenant deployment for you in a dedicated AWS account and private network that serve your company alone. Either way, your database, files and compute are not shared with any other customer.

  • Does any data leave our account?

    Three kinds of request carry data out: what an agent sends to the AI provider you configure, which can be Amazon Bedrock in your own account; calls to the systems you connect, through each one's own API; and requests to the public internet, when an agent reads a public page or code it runs in the sandbox calls out. Page reading can be switched off, and error reporting is off unless you turn it on. We run no control plane and no shared service that holds your data; your deployment pulls our software from our registry, a request that carries none of it.

  • Can your agents change our ERP without anyone approving it?

    No. An ERP write runs only against a person's approval of that exact entry, each approval is used once, and the requester can't approve their own. You can also connect an ERP read only. Other outbound actions, such as a CRM update or a Slack message, ask for approval by default, and you decide per agent which may run on their own.

  • Can the AI see our system credentials?

    No. Credentials are encrypted with AES-256-GCM under a key kept in AWS Secrets Manager, decrypted on the server and added to a request outside the model's context. Agents and the code they run never receive them, and known credential patterns are masked in logs and traces.

  • Which identity providers do you support?

    Any SAML or OIDC provider, one protocol per deployment, including Okta, Microsoft Entra ID, Google and Auth0. Multi-factor authentication follows your provider's policy. With SAML, a session token lasts an hour and every session ends within seven days of sign-in; with OIDC, sessions follow your provider's token lifetimes.

  • What is logged, and for how long?

    Sign-ins and failed attempts, role and permission changes, credential views and rotations, integration and agent changes, and every ERP write with the approval behind it, along with a trace of each agent run. By default activity is kept for a year and security events for two; traces are kept 30 days, their payloads 7. Admins read it in the app, or query it through the API with a service account.

  • Which AI models do your agents use?

    The ones you allow. Bring keys for Anthropic, OpenAI, Google, Amazon Bedrock, DeepInfra, OpenRouter or an OpenAI-compatible endpoint, limit which models each access group may use, and set daily and monthly spend limits.

  • Are you SOC 2 audited?

    Yes. We've completed SOC 2 Type I and Type II audits with an independent auditor.

  • Will you support our security review?

    Yes. We walk your security and IT teams through the deployment, the controls on this page and how they fit your policies before an evaluation starts.

Bring your security team to the first conversation.

Talk to us about your cloud, identity provider, approval rules and security review.

Book a working session