See what Rebase agents do inside your stack

Security

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

Rebase runs single-tenant in your own AWS account. Agents read your systems live, nothing posts to your ledger until a person with the authority approves it, and every action by people and agents is logged.

Illustration of a Rebase deployment: the application, database, credentials and code sandbox inside the customer's own AWS account, and the three things that cross its edge.
Your AWS accounteu-west-1

Private network

  • Rebase

    Single-tenant

  • Database

    Encrypted

  • Credentials

    Sealed separately

  • Code sandbox

    Isolated

Crosses the edge

  • Sign-inYour identity provider
  • Model callsThe provider you choose
  • ERP writesOnly once approved

Security at a glance

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

Deployment
Your own AWS account
Tenancy
Single-tenant, one per customer
Region
The one you choose
Sign-in
SSO with SAML or OIDC
Access
Custom roles and permissions
ERP writes
Approved by a person
Credentials
Encrypted, never shown to the AI
Audit
Every person's and agent's action
Compliance
SOC 2 Type I and Type II

Deployment

It runs in your cloud, not ours.

Every customer gets their own deployment of Rebase, applied in their own AWS account. No database is shared, and no other customer's workload runs beside yours.

  • Your AWS account

    The infrastructure is applied in your account, and the record of how it is configured is kept there too.

  • Single-tenant

    Your database, file storage and compute serve your company alone. Departments get their own organisations inside it, kept apart by the database itself.

  • 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 leaves your account

  • Prompts and context an agent sends to the AI provider you configure, which can be Amazon Bedrock.
  • Error reports, only if you switch them on. They are off by default, and credentials are masked first.

There is no Rebase-hosted control plane, and traces stay in your database. Rebase deploys updates through a role you grant in your account.

Approvals

Nothing posts to your ledger until a person approves it.

Agents prepare the work; the people with the authority decide. The approval is tied to the exact entry, so what gets posted is what was approved.

  • Bound to the exact entry

    An ERP write runs only against a stored approval of its exact contents. Change a line after approval and the write is refused.

  • Used once

    Each approval covers one write. Running it again needs a new one.

  • Segregation of duties

    Whoever requested a write can't approve it. Approvers need approval rights or the Controller role.

  • Read-only connections

    Set an ERP connection to read only and Rebase won't write to it, whatever an agent asks.

  • Every other action, your call

    CRM updates, emails and other outbound actions ask for approval by default. You decide, per agent, which may run on their own.

Illustration of a Rebase 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-10482$18,240.00
Requested by
Omar Haddad, through the AP agent
Approver
Controller
Payload hash
sha256:4f9a…c21e

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

Access

The right people, with exactly the access they need.

Sign-in goes through your identity provider, and roles are yours to define, permission by permission.

  • Single sign-on

    SAML or OIDC, with Okta, Microsoft Entra ID, Google or Auth0. Multi-factor rules come from 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.

  • Short sessions

    Session tokens last an hour and every session ends within seven days. 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. The credentials for your systems get a second layer, and no agent ever handles them.

  • Encrypted at rest

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

  • Encrypted in transit

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

  • Credentials sealed separately

    System credentials are encrypted with AES-256-GCM under a key held in AWS Secrets Manager.

  • Never shown to the AI

    Credentials are added to requests on the server and scrubbed from what comes back, so no agent sees one.

  • Masked in logs

    Credentials are redacted before anything is written to a log or an error report.

  • Backed up

    Automated database backups are kept for 14 days, and the database is protected against deletion.

AI governance

AI you govern like the rest of your infrastructure.

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

  1. 01

    Your model keys

    Run on your own provider accounts: Anthropic, OpenAI, Google, Amazon Bedrock or any OpenAI-compatible endpoint.

  2. 02

    Approved models only

    Decide which models each group of people may use.

  3. 03

    Spend caps

    Set daily and monthly limits per group. A run that reaches one stops.

  4. 04

    Isolated code execution

    Code an agent writes runs in a throwaway container with no privileges, no credentials and no route into your private network.

  5. 05

    Every call traced

    Each run records its model calls and tool calls, so you can see what an agent did and in what order.

  6. 06

    Versioned instructions

    Agent instructions are versioned, so you can see what an agent was told when it did the work.

Audit

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

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

  • Every change people make

    Sign-ins and failed attempts, role and permission changes, credential views and rotations, and changes to integrations and agents.

  • Every step agents take

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

  • Approvals you can reconstruct

    Each approval keeps the exact payload, who requested it, who approved it and the run that used it.

  • Kept in your database

    By default, activity is kept for a year and security events for two. Pull it through the API into your own tools.

Illustration of a Rebase activity log: sign-ins, a role change, a credential rotation, an approved ERP posting 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-10482 · $18,240.00

  5. 11:05
    AP agenterp.document.posted

    PI-10482 · approved by Sara Malik

  6. 11:48
    Unknownauth.login.failed

    3 attempts

Kept 365 days

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?

    In your own AWS account, in the region you choose — bring your own cloud (BYOC) is supported first class — or, if you would rather we run it, in a private VPC we host for you alone. Either way Rebase is deployed single-tenant, so your database and files are not shared with any other customer.

  • Does any data leave our account?

    What an agent sends to the AI model provider you configure, which can be Amazon Bedrock. There is no Rebase-hosted control plane, traces stay in your database, and error reporting is off unless you turn it on.

  • Can Rebase 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.

  • Can the AI see our system credentials?

    No. Credentials are encrypted with AES-256-GCM, added to requests on the server and scrubbed from responses. Agents and the code they run never receive them.

  • Which identity providers do you support?

    Any SAML or OIDC provider, including Okta, Microsoft Entra ID, Google and Auth0. Multi-factor authentication follows your provider's policy.

  • What is logged, and for how long?

    Sign-ins, access and role changes, credential views, integration and agent changes, and every ERP write, along with a trace of each agent run. By default activity is kept for a year and security events for two.

  • Which AI models does Rebase use?

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

  • Is Rebase SOC 2 audited?

    Yes. Rebase has 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, your identity provider, your approval rules and how your review works.