Security
Security you can verify,
not just trust
Handing raw cloud keys to an AI agent is the risk Mesoplane removes. So we hold ourselves to one bar: connecting us must be strictly safer than the alternative, and you should never trust us with anything you can't take back.
The connection
A handshake, not a secret
There is no API key sitting in our database with your name on it. The connection is a role in your account that we are allowed to borrow, briefly, and that you can revoke in one click.
Threat model
We designed for the day we get breached
Most vendors ask "how do we keep your secrets safe?" We asked a harder question first: "what if someone gets all the way into Mesoplane?" If the answer is scary, the design is wrong.
So we built it so there is nothing worth stealing, and so you can cut us off without asking.
- ✗ your AWS access keys · none exist
- ✗ long-lived cloud credentials · never stored
- ✗ a way to stop you revoking them · the role is yours
- ✓ an audit trail · that names them too
How it holds up
Six guarantees, not six promises
No credentials at rest
We call sts:AssumeRole and get short-lived sessions that expire on their own. No access keys to store, so none to leak.
The kill switch is yours
The role lives in your account. Delete the CloudFormation stack and every path we had is gone instantly. No ticket, no waiting.
Agents never hold keys
Agents talk to our control plane, never to your cloud. Every request is re-checked server-side. A prompt injection can ask; it can't authorize itself.
Every action is attributed
Sessions carry sts:SourceIdentity, so your CloudTrail names the exact agent seat that acted, not a shared principal.
Risky actions pause for you
Operations are typed with risk tiers. Reads run, writes wait for approval, destructive ones capture a rollback envelope first.
Tenants are isolated
Every record is scoped to its workspace and fails closed for unknown ones. Sessions are signed; TOTP and hardware keys (WebAuthn) are supported.
The difference
Pasted keys vs. a governed connection
Defense in depth
Watch a bad request die four times
Say a prompt injection convinces an agent to try delete production database. Here is every wall it hits.
No credentials to use
The agent has nothing to call AWS with. It can only ask Mesoplane.
Server-side validation
Identity, workspace, and role are re-checked. The ask doesn't grant the right.
Risk policy + human approval
A destructive op is high-risk. It pauses in the approvals inbox for a person.
Ledger + rollback
Even if approved, the attempt is recorded and the before-state is captured to undo.
FAQ
Security questions, answered
Does Mesoplane store my AWS credentials?
No. Mesoplane never stores long-lived cloud credentials. It reaches your account by calling sts:AssumeRole on a role that lives in your account, and receives short-lived STS session credentials that expire on their own. There are no access keys to store, so there are none to leak.
How do I revoke Mesoplane's access to my account?
Delete the CloudFormation stack you launched when you connected. The IAM role lives in your account, so removing it cuts every path Mesoplane had, instantly, without a support ticket. Pausing a connection on our side also fails closed and refuses all operations.
What is the ExternalId in the AssumeRole trust policy?
It is the standard AWS defense against the confused-deputy problem. The ExternalId is unique to your workspace, so even someone who knows your role ARN cannot get Mesoplane to assume the role on their behalf.
Can a prompt injection make an agent delete my infrastructure?
It can ask, but it cannot grant itself permission. The agent holds no credentials, and every request is re-validated server-side against identity, workspace, role, and guardrail policy. Risky operations pause for a human, and destructive ones capture a rollback envelope before they run.
What happens if Mesoplane itself is compromised?
That is the case we designed for. There are no stored cloud keys to steal, sessions are short-lived and scoped, every action is on a tamper-evident ledger, and you can delete the role in your account at any moment. The blast radius is bounded by design, not by our promises.
How are different customers kept separate?
Every workspace-owned record is scoped to its workspace, and cloud operations fail closed for unknown workspaces. Sessions are signed server-side, and the console supports TOTP and hardware security keys (WebAuthn), with Google sign-in restrictable to your email domain.
Try the safe path first
Connect an AWS account read-only in minutes. See every guarantee on this page in action, with nothing you can't take back.
Found a vulnerability? Report it through the console or your onboarding contact and we will respond quickly.