--- title: "Security: finance AI agents in your own AWS account — Empty Spaces" description: "The platform runs single-tenant in your AWS account or a dedicated one we run for you. ERP writes need a person's approval; credentials never reach the AI." url: https://emptyspaces.ai/security language: en --- 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 session](https://emptyspaces.ai/contact-us) [Security FAQ](https://emptyspaces.ai/security#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. ## 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. 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 ](https://emptyspaces.ai/platform#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. 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](https://emptyspaces.ai/contact-us)