ekai runs in your cloud. You keep the keys.
A brief for the team that has to approve this. What gets installed, what it can reach, and how it is installed without you handing anyone a credential.
Everything runs inside your boundary.
ekai installs as an ordinary workload in your account. It reads from your systems over connections you authorise, calls a model endpoint you control, and writes to a datastore you own. There is no ekai tenant on the other side, because there is no other side.
- Application
- Reads, ranks, and prepares. Runs as containers you can scale, patch, and restart.
- Datastore
- Your context graph. Lives in your account, encrypted with your keys.
- Key store
- You hold the encryption keys. ekai asks for them, it never owns them.
- Model endpoint
- Your inference. Bedrock, Azure OpenAI, or a model on your own hardware.
- No inbound connection from us. Your deployment does not send your content anywhere.
- No shared inference. Your prompts and your context reach the model endpoint you configured and nothing else.
- Updates are releases you choose to apply, on your own change control.
- Tear it down and the context goes with it. There is no copy on our side to delete.
One template. No credential ever leaves your account.
You launch a stack in your own console. It creates a role that trusts ekai as an identity provider, scoped to the account and region you choose. ekai exchanges a short lived token to provision, and that token expires in minutes.
Step 1
Launch the stack
Open the template in your own cloud console and read every resource before you create anything. It is a normal stack in your account, and it goes through whatever review your team already runs.
Step 2
The trust is created
The stack registers ekai as an OIDC identity provider and creates a role that trusts it. There is no access key and no shared secret, so there is nothing to rotate and nothing to leak.
Step 3
ekai provisions
ekai requests a short lived token against that trust, assumes the role, and creates the workload in your account. The token expires in minutes and cannot be reused.
Step 4
You own it
The deployment is yours from that moment. Scale it, patch it, audit it, or delete it from your own console. Every action ekai took is in your own audit log.
Where you can install it today
- AWS
- CloudFormation stackLaunch from your console into the account and region you choose.
- Azure
- ARM templateDeploy into your own subscription and resource group.
- GCP
- Guided installSupported today and arranged with us. A one click template is on the way.
Delete the role and the trust ends immediately. There is no second path in.
What the role can do, and what ekai never gets.
The install role can
- Create the ekai workload, its datastore, and its networking, inside the account and region you scoped it to.
- Read the configuration you set during install.
- Write logs and metrics to your own monitoring.
ekai never gets
- A long lived credential. The trust issues short lived tokens and nothing else.
- Your email, calendar, meeting, or chat content. That is read by the deployment inside your account, never by us.
- Reach beyond the account and region the role is scoped to.
- A way back in once you delete the role.
Before you start
- An AWS account or Azure subscription you can create resources in.
- Permission to create an identity provider and a role.
- A model endpoint. Bedrock, Azure OpenAI, or your own.
- About 30 minutes.
For the security review
- Your data never leaves your cloud account. No vendor access, including ours.
- AES-256 at rest, TLS 1.2 or higher in transit. You hold the encryption keys.
- No shared inference. No model trained on your data.
- Runs under the certifications already in place in your environment. Data residency is set by the region you deploy into.
- Every action taken during install is recorded in your own audit log.
Architecture questions and security questionnaires are welcome.
Or write to hello@yourekai.com