Security review
In your account. Under your control.
Langrove runs inside your company's AWS account. We reach it through one role that's listed in full, logged by AWS and yours to remove at any time. Everything your reviewer needs is on this page, checked against our stack template and code on 29 September 2026.
- Your data stays in your accountTables, files, sessions and logs live in your AWS account.
- One role, listed in fullOur only way in. Every permission is in your stack template and below.
- Short, logged sessionsAn hour at most, locked to your ExternalId and recorded by CloudTrail.
- You hold the off switchDelete our role and your apps keep running.
- Only people go liveAI editors have no deploy or rollback tool. You choose who ships.
- Encrypted at rest and in transitAWS-managed keys for stored data, and HTTPS with TLS 1.2 or later.
Where each part runs
- In your AWS account, in Europe, across availability zones: your tables (Aurora DSQL), files (S3), search index (S3 Vectors), secrets (Parameter Store), code, agents and schedules.
- At the edge: CloudFront serves your apps worldwide. As CloudFront requires, its firewall and certificate are created in your account in us-east-1, so that region must be allowed.
- In Langrove's own AWS account: the console, the compiler and the AI editor connection.
What stays with you, and what we see
Stays in your AWS account
- Your tables and every row in them
- Files and the document search index
- Your users' sessions and passkeys
- Logs and metrics, in your CloudWatch
- Schedules, queues and live-update channels
- Your users' requests, answered in your account
What Langrove sees
- Your apps' design: data models, code, access rules and flows
- Test rows your AI editor works with
- Data you open in our console, read live through our role
- Your team's accounts, and who may edit which project
- Daily usage per project: requests and run time
- Keys you enter for sign-in providers and outside APIs, stored encrypted and placed in your account
- Sign-in emails, until a project has its own sender
- Messages to the console's chat assistant, which go to Google Gemini
Two services you choose also get data: agent prompts go to your model provider, with your key, and document search ranks results with Amazon Bedrock in Frankfurt. You can switch ranking off for each knowledge base.
Our access: one role, with guard rails
Langrove reaches your account through one IAM role, defined in your stack template. This is what limits it.
- Scoped to your Langrove stack. Every permission is limited to your stack's own resources, apart from three that AWS offers no narrower scope for, shown in the list below.
- Short sessions. Each lasts an hour at most and needs your stack's ExternalId.
- Logged in your account. CloudTrail records every session and management call. To log its file reads and function calls too, add S3 and Lambda data events to a trail of your own.
- Can't change your security. It can't create roles, edit policies or use CloudFormation. The one role it can pass goes to EventBridge Scheduler, and can only queue messages for your apps.
- Writes secrets, can't read them. It can place keys in your secret store, with no permission to read them back.
What it's for: publishing your releases, applying table changes, and showing your data and logs in our console, so it can read them. Like any deploy access, code it publishes can use its project's secrets when it runs.
See all 12 permissions
<your-stack>-accesssessions last at most 1 hourneeds an ExternalId
| Statement | Actions | Scope |
|---|---|---|
| ManageCompiledBundles | s3:PutObject, s3:GetObject, s3:DeleteObject | the releases folder of one bucket |
| ListBundlesOnly | s3:ListBucket | that same folder |
| PlaceSecretsButNeverReadThem | ssm:PutParameter, ssm:DeleteParameter | this stack's parameters; no GetParameter |
| InvokeThisRuntime | lambda:InvokeFunction | the router and the executor |
| ApplySchema | dsql:DbConnectAdmin | your cluster, as admin |
| CustomDomainCertsAndAliases | acm:RequestCertificate, acm:DescribeCertificate | any certificate in the account; ACM can't scope this sooner |
| AttachDomainsToThisDistribution | cloudfront:GetDistribution, cloudfront:GetDistributionConfig, cloudfront:UpdateDistribution | this stack's distribution, its whole configuration |
| ManageFlowSchedules | scheduler:CreateSchedule, scheduler:UpdateSchedule, scheduler:DeleteSchedule, scheduler:GetSchedule | schedules named devcore-* |
| ListScheduleNames | scheduler:ListSchedules | names of every schedule in the account |
| PassOnlyTheSchedulerRole | iam:PassRole | one role, to EventBridge Scheduler only |
| ReadTelemetry | logs:FilterLogEvents, logs:GetLogEvents, logs:StartQuery, logs:GetQueryResults, logs:DescribeLogStreams, logs:DescribeSubscriptionFilters | five log groups |
| ReadMetrics | cloudwatch:GetMetricData, cloudwatch:ListMetrics | every metric in the account; AWS can't scope this |
The AI editor works within limits
It connects over MCP as the person who added it, with that person's view or edit rights on one project. Remove the person and it's cut off at once.
It can't
- Deploy or roll back. It has no tool for either.
- Use the secrets screen, or delete a project or an access
- Upload, move or delete your website's files
- Read or write live rows through its table tools
It can
- Change code and table structure in dev. Dev shares production's tables, so removed columns are kept for 15 days.
- Set up sign-in and API connections, including their secrets
- Run test calls that use your real keys
- Read and end your agents' live conversations
Your apps don't depend on us
Delete our role and our access ends at once. Your apps keep running. Sign-in emails we send for you also keep going, on a separate key, until each project has its own sender. If Langrove itself disappeared:
Keeps working
- Every request to your apps
- Sign-in, for projects with their own email sender
- Agents, flows and schedules
- Document search
Needs Langrove
- The console and the AI editor connection
- New releases and runtime versions
- Sign-in emails we send for you
Already yours
- Every table, file and secret
- Each release, as a readable file in your bucket
- The stack, running in your account
This applies when the runtime is in your own AWS account. In an account we run for you, we manage it on your behalf.
Who looks after what
| AWS | Langrove | You | |
|---|---|---|---|
| Hardware, network, regions | Runs them | ||
| Lambda, Aurora DSQL, S3 and the other services | Runs them | ||
| The runtime's roles, limits and defaults | Designs and publishes each version | Applies updates | |
| Change checks, sign-in, access rules, the sandbox | Builds them | ||
| Your data model, code and access rules | Decides them, with your AI editor | ||
| Who may sign in to your apps | Provides the methods | Configures them, manages users | |
| Backups | Sets them up |
Updates, on your schedule
- Nothing changes until you say so. We publish runtime versions, and your AWS admin applies each one to both stacks as a CloudFormation update.
- You see the change first. The change set lists which resources change before you apply it.
- Table changes only add. Our role adds new database columns when a version rolls out, so your current code keeps working.
- Roll back in about 30 seconds. Rolling back a release moves a pointer and rebuilds nothing, and your data stays exactly as it is.