Security & architecture
Your data never leaves your cloud. That's the architecture.
Kuudo deploys MCP servers, agents, and a data lake inside your own cloud account. Your AI clients connect straight to them. Your Amazon data never touches our infrastructure: not stored, not cached, not proxied.
The dashed line stops at the wall. We are not in the data path.
The abstraction ladder
Three places your data can live. Two of them aren't yours.
Every tool you connect puts your data on one of these rungs. Kuudo is built on one rule, carried to its logical end: don't hold what isn't yours.
Paste a report, a CSV, a spreadsheet, a PDF, a prompt into a chat session and they have full visibility. It all runs through their pipeline — and what works for you will end up improving a product your competitors also use.
Your usage data lives in their system — and it feeds their product. The data you call, the actions you run, the context you supply: all of it is commoditized and rolled into features every subscriber gets. It feels like a moat, until your use case ships as everyone's "new feature."
The MCP servers, the agents, and the data lake all deploy into a cloud account you own. We're not in the flow at all. What's left to trust is a thin control plane — the only thing we have to secure.
Isolation by design
Your own cloud account, not a database row.
Multi-tenant platforms separate customers with permissions and query filters — one bug away from someone else's data. Kuudo has nothing to partition.
How most platforms isolate you
Everyone's data sits in one shared system. A tenant ID and an access rule are all that stand between your numbers and the next customer's.
How Kuudo isolates you
You bring the cloud account, and you choose the platform — AWS, Google Cloud, Azure, or Cloudflare. Kuudo deploys into it; we never hold it. The boundary around your data is the one those platforms already enforce: your IAM, your network, your keys.
It answers to your compliance regime — your SOC 2 scope, your residency rules, your keys — with no vendor exception. And what accumulates over time — the data, the learning, the playbooks — accumulates in storage only you can reach. That's what makes it a moat, your moat.
Two planes, two answers
Your column is long. Ours is short on purpose.
The honest way to read a security page is to ask one question: what does the vendor actually hold? Here is the complete answer.
The data plane
Yours — in your cloud- Everything that touches Amazon data runs in your own cloud account — MCP servers, Agent Flow's lake, Atlas retrieval, Skills.
- Direct connections. Requests, API responses, and outputs travel between your AI client and your resources. Never through Kuudo.
- We don't host, copy, cache, inspect, or retrieve your Amazon business data or the outputs built from it.
- Never used for training. Nothing in your data trains, fine-tunes, or improves any model — ours or anyone else's.
- Encrypted under your keys, in your storage, governed by your cloud's controls.
The control plane
Ours — the complete list- Scoped orchestration credentials and deployment configuration you authorize us to use to stand up and manage your environment. Plus health telemetry: that a job ran, never what it carried.
- Encrypted Amazon refresh tokens (and client secrets in bring-your-own-app mode), granted through Amazon's standard Login with Amazon (LWA) flow — Amazon's own consent screen scopes the permissions, and you can revoke them from your Amazon account at any time. Tokens are exchanged for short-lived access tokens issued to runtimes you authorize; the service never proxies your Amazon API traffic.
Yours by design
What we can't see.
Your edge isn't just the data. It's the prompts you've refined, the playbooks you've built, the way you actually run the business. None of it passes through us — so none of it is ours to see, hold, or learn from.
Everything the AI learns while working for you — the corrections, the judgment calls, the wins — compounds in your cloud account, not in anyone's training set. By design, we can't see any of it. That is yours.
Control-plane security
Receipts, not promises.
The control plane is built and run by the same team that built Openbridge — ten years running production Amazon data infrastructure, with a security program that passed Amazon's SP-API security review for developers handling PII, across every control domain. These are the standing controls behind it.
TLS 1.2+ everywhere, TLS 1.3 on public load balancers. Tokens and secrets encrypted at rest with AWS KMS. Passwords stored only as salted hashes.
Annual, independent, plus after significant changes. OWASP WSTG v4.2, ASVS Level 2, NIST SP 800-115. Latest findings closed within days.
Amazon Inspector scans at least monthly, inside and out. Remediation SLAs: 7 days critical, 30 days high.
GuardDuty + Security Hub run continuously across production, staging, and development. No "lighter" environment exists.
CodeQL static analysis, Dependabot dependency alerts, documented change management. Processing systems live in private subnets with no public endpoints.
Least privilege by documented policy. Quarterly access reviews across every employee and service account. Privileged accounts managed as their own control area.
AWS WAF filters and blocks malicious traffic on every public control-plane surface and prevents unauthorized data egress at the application layer.
A documented program aligned with ISO 27001/27002 and the NIST CSF: version-controlled policies, annual senior-management review, third-party risk management.
Independent validation
Checked by people who don't work here.
Amazon SP-API security review: passed
January 2026, PII scope. Governance, data security, endpoint security, secure development, vulnerability management, cloud security, and hosted-software controls — evidence provided for each.
Amazon partner programs
Amazon Ads Verified Partner and Amazon Service Provider Network partner.
Audited platform inheritance
The control plane runs on AWS, inheriting the physical and infrastructure controls of a continuously audited platform: SOC 2 Type II, ISO 27001.
FAQ
The questions every security review asks.
Familiar questions — and one root answer underneath all of them: we are not in the data path.
Where exactly is my data stored?
In your own cloud account — AWS, Google Cloud, Azure, or Cloudflare — in whatever region you choose. We don't have a datacenter location to disclose because we don't have your data. Your residency requirements are satisfied by your own cloud configuration, not by a promise from us.
Who at Kuudo can see my data?
No one — structurally, not procedurally. There is no Kuudo-side system that contains your Amazon business data, so there's no access for a policy to restrict, no read for an audit log to record, and no "documented reason" process to trust. What our systems can see is deployment telemetry: that a job ran, that a service is healthy. Never what it carried.
What does Kuudo actually hold, then?
Two things. Scoped orchestration credentials and deployment configuration you authorize us to use to stand up and manage your environment. And, if you use our Amazon authorization service, encrypted refresh tokens exchanged for short-lived access tokens issued to runtimes you authorize — the service never proxies your Amazon API traffic. That's the complete list, and every control on this page exists to protect it.
How does Amazon authorization work?
Through Amazon's own front door. Kuudo uses standard Login with Amazon (LWA) — the same OAuth flow Amazon requires of every SP-API and Ads developer. You grant access on Amazon's consent screen, Amazon scopes what the grant can touch, and you can review or revoke it from your Amazon account at any time. The authorization protocol and the permissions are always under your control — and holding an authorization still gives us no path to the data you collect with it, because that data flows straight into your own cloud account.
Is my data used to train AI models?
Never by us — and there's no configuration in which it could be. Your AI client connects directly to resources in your own cloud account; nothing routes through Kuudo, so there is nothing for us to collect, retain, or train on. Which model provider your client uses, and on what terms, stays your choice and your agreement — exactly where that decision belongs.
What happens when I cancel?
Your data stays exactly where it always was — in your storage, in your cloud account. The managed services wind down without the control plane to orchestrate them, but there is nothing to export and nothing to retrieve: the lake, the history, and everything your agents built are already yours. On our side, you revoke the scoped keys you granted us and we delete your tokens and control-plane records. There is no 30-day purge window to monitor and no deletion audit to request, because there was never a vendor copy of your data to destroy. Offboarding from Kuudo is an exercise in revoking, not retrieving.
What happens if Kuudo has a security incident?
The blast radius is the control plane, because that's all there is: a breach of our systems cannot expose your Amazon business data — it isn't in them. Worst case involves encrypted tokens and scoped keys, both of which you can revoke immediately from your own consoles. We maintain a documented incident response plan and will notify you promptly with what you need to meet your own regulatory obligations.
What about SOC 2, ISO 27001, GDPR, and Amazon's requirements?
Two answers, one for each plane. The control plane: built and run by the same team behind Openbridge, whose security program passed Amazon's SP-API security review for developers handling PII (January 2026) and runs on AWS's continuously audited platform (SOC 2 Type II, ISO 27001), with a program aligned to ISO 27001/27002 and the NIST CSF. GDPR and CCPA terms are covered in our DPA, including Standard Contractual Clauses and the UK Addendum. The data plane: it runs in your cloud, so it sits inside your existing compliance regime — your SOC 2 scope, your residency rules, your key management, with no vendor exception to explain to an auditor.
How do I verify any of this?
Deploy it and look. Every claim on this page is checkable against your own cloud console: the resources in your account, the IAM boundaries, the absence of any data path through us. You can even pen-test your own deployment, under your own rules — no permission letter from us required. For the control plane, the independent checks are the verification: Amazon's SP-API security review, passed across every control domain, and AWS's continuously audited platform.
Private beta
The strongest security answer is a deployment you own.
Bring us the Amazon workflow you want to run in your own cloud. We'll map the security model, deployment fit, and private-beta onboarding plan with you.
Security posture last updated July 19, 2026