Skip to content

Cloud Security Posture ManagementAvailable

Cloud posture management that stays inside your perimeter.

kaveo scans your cloud accounts with read-only access from inside your own environment, so security teams that cannot hand their configuration to a vendor still get findings, attack paths and compliance evidence they can verify.

Book a demoTalk to usRead the docs

Runs as a Docker Compose stack in your environment.

Nothing leaves by defaultPlan of a kaveo deployment inside your perimeter. On the left, your AWS accounts: each carries the read-only role kaveo-readonly, admitted only with a matching ExternalId of at least 8 characters, with the SecurityAudit and ViewOnlyAccess managed policies and a one-hour session. A dashed slot in each account marks the separate write role, kaveo-remediation, which is not deployed by default. Read calls only run from each account's role into the kaveo stack, one Docker Compose project you operate, plus an optional local model that is not started by default. The stack's AI provider is offline by default. The stack writes observations to its evidence store, where they are append-only. Hidden lines leave the stack only through a closed gate in the perimeter, toward three opt-in destinations that stay off until configured: a hosted AI provider, which would receive prompts built from findings; Slack, Jira, webhooks, email and other alert channels; and GitHub remediation pull requests. By default the only runtime egress is sts:AssumeRole plus read-only API calls to the accounts you connect. Note 1: AWS is covered in depth; Azure, GCP, Kubernetes and GitHub have one collector and one detector each.kaveo — one Docker Compose stackYOUR PERIMETERYOUR AWS ACCOUNTSkaveo · DOCKER COMPOSEAWS accountkaveo-readonlyAWS accountkaveo-readonlyAWS accountkaveo-readonlyAWS accountkaveo-readonlykaveo-remediation · write roleNOT DEPLOYED BY DEFAULTEXTERNALID ≥ 8 CHARS · 1-HR SESSIONSecurityAudit + ViewOnlyAccess1Azure, GCP, Kubernetes, GitHub:one collector, one detector eachREAD CALLSONLYkaveo stackAI PROVIDER: OFFLINE (DEFAULT)observationsappend-onlyevidence storelocal modelOPTIONAL · NOT STARTED BY DEFAULTOPT-IN · OFF UNTIL CONFIGUREDhosted AI providerRECEIVES PROMPTSBUILT FROM FINDINGSSlack · Jira · webhooksEMAIL · ALERT CHANNELSGitHub remediation PRsNothing leaves by defaultPlan of a kaveo deployment inside your perimeter. On the left, your AWS accounts: each carries the read-only role kaveo-readonly, admitted only with a matching ExternalId of at least 8 characters, with the SecurityAudit and ViewOnlyAccess managed policies and a one-hour session. A dashed slot in each account marks the separate write role, kaveo-remediation, which is not deployed by default. Read calls only run from each account's role into the kaveo stack, one Docker Compose project you operate, plus an optional local model that is not started by default. The stack's AI provider is offline by default. The stack writes observations to its evidence store, where they are append-only. Hidden lines leave the stack only through a closed gate in the perimeter, toward three opt-in destinations that stay off until configured: a hosted AI provider, which would receive prompts built from findings; Slack, Jira, webhooks, email and other alert channels; and GitHub remediation pull requests. By default the only runtime egress is sts:AssumeRole plus read-only API calls to the accounts you connect. Note 1: AWS is covered in depth; Azure, GCP, Kubernetes and GitHub have one collector and one detector each.YOUR PERIMETERYOUR AWS ACCOUNTSkaveo · DOCKER COMPOSE1AWS accountkaveo-readonlyAWS accountkaveo-readonlyAWS accountkaveo-readonlyAWS accountkaveo-readonlykaveo-remediation · write roleNOT DEPLOYED BY DEFAULTEXTERNALID ≥ 8 CHARSSecurityAudit + ViewOnlyAccessREAD CALLS ONLYkaveo stackAI PROVIDER: OFFLINE (DEFAULT)observations · append-onlyevidence storelocal modelOPTIONAL · OFF BY DEFAULTOPT-IN · OFF UNTIL CONFIGUREDhosted AI providerRECEIVES PROMPTSBUILT FROM FINDINGSSlack · Jira · webhooksEMAIL · ALERT CHANNELSGitHub remediation PRs
Vendor egress
None by default
Scan access
Read-only role
Deployment
Your own environment
Findings
Evidence-backed

Documented: 97 detectors · 48 collectors · 10 frameworks · 7 MCP tools · see the docs

Nothing leaves by defaultPlan of a kaveo deployment inside your perimeter. On the left, your AWS accounts: each carries the read-only role kaveo-readonly, admitted only with a matching ExternalId of at least 8 characters, with the SecurityAudit and ViewOnlyAccess managed policies and a one-hour session. A dashed slot in each account marks the separate write role, kaveo-remediation, which is not deployed by default. Read calls only run from each account's role into the kaveo stack, one Docker Compose project you operate, plus an optional local model that is not started by default. The stack's AI provider is offline by default. The stack writes observations to its evidence store, where they are append-only. Hidden lines leave the stack only through a closed gate in the perimeter, toward three opt-in destinations that stay off until configured: a hosted AI provider, which would receive prompts built from findings; Slack, Jira, webhooks, email and other alert channels; and GitHub remediation pull requests. By default the only runtime egress is sts:AssumeRole plus read-only API calls to the accounts you connect. Note 1: AWS is covered in depth; Azure, GCP, Kubernetes and GitHub have one collector and one detector each.kaveo — one Docker Compose stackYOUR PERIMETERYOUR AWS ACCOUNTSkaveo · DOCKER COMPOSEAWS accountkaveo-readonlyAWS accountkaveo-readonlyAWS accountkaveo-readonlyAWS accountkaveo-readonlykaveo-remediation · write roleNOT DEPLOYED BY DEFAULTEXTERNALID ≥ 8 CHARS · 1-HR SESSIONSecurityAudit + ViewOnlyAccess1Azure, GCP, Kubernetes, GitHub:one collector, one detector eachREAD CALLSONLYkaveo stackAI PROVIDER: OFFLINE (DEFAULT)observationsappend-onlyevidence storelocal modelOPTIONAL · NOT STARTED BY DEFAULTOPT-IN · OFF UNTIL CONFIGUREDhosted AI providerRECEIVES PROMPTSBUILT FROM FINDINGSSlack · Jira · webhooksEMAIL · ALERT CHANNELSGitHub remediation PRs

The problem

Posture tools ask for trust they cannot show.

  1. Your configuration leaves to be judged

    A hosted scanner copies your cloud configuration into its own platform before it can say anything about it. For regulated or isolated environments, that copy is the part the review board will not sign.

  2. Findings arrive without their proof

    "Bucket is public" is only as good as the API call behind it. When that evidence is not kept, every audit starts by re-proving what the tool already saw.

  3. A long list with no order

    Hundreds of findings sorted by severity say little about which ones chain together into a path from the internet to your data, or which single change removes the most of them.

How it works

Read, record, decide, then explain.

  1. Read with a role you control

    kaveo assumes a read-only role in each AWS account, pinned by an ExternalId, and calls only read APIs. What each collector reads is written to an append-only evidence ledger, per API call and per page for collectors such as IAM.

  2. Decide in deterministic code

    Detectors are pure functions over what the scan collected, so the same account state gives the same findings. Graph queries then trace paths from internet-facing resources to crown jewels, and the choke points they share.

  3. Explain with citations, or not at all

    The AI layer explains and prioritizes findings but never creates one. A claim with no citation, or one that does not resolve to a stored observation, is dropped before it is saved. AI is off by default, and everything else works without it.

Every claim cites a stored observationSection through kaveo, one level per stage, inside your perimeter. Accounts: three AWS accounts. Collection: 44 AWS collectors make read calls only. Evidence: what each collector reads becomes an observation in an append-only ledger, one per collector run, or one per API call and page for collectors such as IAM. Each observation records the call and a SHA-256 hash of what it returned, not the payload. A database trigger rejects edits and direct deletes. Findings: 93 deterministic AWS detectors; the same state always gives the same findings, and each finding cites the observations behind it. Citation gate: every claim from the AI layer is checked before anything is stored. AI layer: five stages, with an offline stub by default. Four claims rise from the AI layer. Two cite observation ids they were given; they pass the gate and are stored as AI output together with its citations. One claim has no citation and is dropped at the gate. One cites an id it was not given and is dropped. If no claim survives, nothing is stored. Note 1: grounding proves each cited observation exists and was supplied, not that the model read it correctly.YOUR PERIMETERACCOUNTSAWS accountAWS accountAWS accountCOLLECTION44 AWS COLLECTORS · READ CALLS ONLYEVIDENCEeach row: call + SHA-256 of its resultobsFINDINGSfindingfindingfinding93 AWS DETECTORS · SAME IN → SAME OUTstored AI outputWITH ITS CITATIONSif no claim survives, nothing is storedCITATION GATEno citation → droppedcites an id it wasnot given → droppedEVERY CLAIM CHECKED1AI LAYERFIVE STAGES · OFFLINE STUB BY DEFAULTEvery claim cites a stored observationSection through kaveo, one level per stage, inside your perimeter. Accounts: three AWS accounts. Collection: 44 AWS collectors make read calls only. Evidence: what each collector reads becomes an observation in an append-only ledger, one per collector run, or one per API call and page for collectors such as IAM. Each observation records the call and a SHA-256 hash of what it returned, not the payload. A database trigger rejects edits and direct deletes. Findings: 93 deterministic AWS detectors; the same state always gives the same findings, and each finding cites the observations behind it. Citation gate: every claim from the AI layer is checked before anything is stored. AI layer: five stages, with an offline stub by default. Four claims rise from the AI layer. Two cite observation ids they were given; they pass the gate and are stored as AI output together with its citations. One claim has no citation and is dropped at the gate. One cites an id it was not given and is dropped. If no claim survives, nothing is stored. Note 1: grounding proves each cited observation exists and was supplied, not that the model read it correctly.YOUR PERIMETERaccountaccountaccount44 AWS COLLECTORS · READ-ONLYobsfinding93 AWS DETECTORSSAME STATE, SAME FINDINGSstored AI outputWITH ITS CITATIONSif no claim survives,nothing is storedno citation → droppedcites an id it wasnot given → droppedEVERY CLAIM CHECKED1FIVE STAGESOFFLINE STUB BY DEFAULTAWS ACCOUNTSCOLLECTIONEVIDENCEcall + SHA-256 per rowFINDINGSCITATION GATEAI LAYER
EXHIBIT AWhat one stored observation holds
Call
The read it records: one collector run, or for IAM one API call and page
Hash
SHA-256 of the resources that read returned
Payload
Not stored
Edits
Rejected by the database

Described in plain terms. The ledger keeps a SHA-256 hash of what a read returned, not the payload itself, and a finding cites the observation behind it.

Stations in the drawing

What happens in one scan.

  1. S1Collect read-only

    Assumes kaveo-readonly with your ExternalId. Collectors call read APIs only, and a denied assume fails the scan.

    SecurityAudit + ViewOnlyAccesskaveo/connect-accounts

  2. S2Ledger

    Each collector run, and for collectors such as IAM each API call and page, becomes a ledger entry with a SHA-256 hash of what it returned. The database rejects edits and direct deletes.

    SHA-256 per observationkaveo/grounded-ai

  3. S3Detect

    Detectors are pure functions of the collected resources and edges, so the same state always gives the same findings.

    deterministickaveo/detection

  4. S4Validate paths

    On a live AWS scan each permission hop is simulated with a read-only call. A toxic-path finding is shown only when every simulated hop is allowed.

    iam:SimulatePrincipalPolicykaveo/detection

  5. S5Cite

    AI claims that cite no observation, or an id that does not resolve, are dropped before anything is stored. AI runs offline by default.

    citation gatekaveo/grounded-ai

Capabilities

What kaveo does with what it reads.

An attack path, validated hop by hopTraverse of one AWS account inside your perimeter. The perimeter's left edge has three openings, each an internet-facing resource the internet can reach. The first opening runs as a role; the second and third each run as an instance role. The instance role can assume a third role, and the first role can pass role to the same role, so all three paths cross it: a choke point. Choke points are ranked by the paths through them: one path is medium, two high, three or more critical. Fix it and every path through it is cut. From the choke point, the role can read a crown jewel: an RDS instance or cluster, S3 bucket or DynamoDB table, an admin-bearing IAM principal, or a resource tagged crown-jewel, sensitive or with a data-classification tag. A name alone never makes one. Paths are walked for up to 8 hops from an internet-facing resource. Structural legs, such as runs as role and can read, are accepted from the relationship kaveo stored at scan time. The two permission hops, can assume and can pass role to, are each simulated with the read-only iam:SimulatePrincipalPolicy call; both are allowed, and each result is stored as an observation in the append-only ledger. Three particles walk the three paths and rest at the crown jewel. A fourth branch, the instance role's iam:PassRole to another role, simulates as denied and stops there, so that chain stays hidden. Note 1: toxic-path findings start suppressed; a chain is shown only when every simulated hop is allowed.up to 8 hops from an internet-facing resourceINTERNETinternet-facingYOUR PERIMETER · AWS ACCOUNTiam:PassRole simulated · deniedthe chain stays hiddenruns as roleruns as rolestored edgecan pass role tocan assumecan readroleinstance roleSIMULATED · ALLOWEDiam:SimulatePrincipalPolicystored as an observationroleCHOKE POINT · 3 PATHS CROSS1 MEDIUM · 2 HIGH · 3+ CRITICALFix it and every path through it is cut.crown jewelRDS · S3 · DYNAMODBADMIN IAM · SENSITIVE TAGa name alone never makes onerole1An attack path, validated hop by hopTraverse of one AWS account inside your perimeter. The perimeter's left edge has three openings, each an internet-facing resource the internet can reach. The first opening runs as a role; the second and third each run as an instance role. The instance role can assume a third role, and the first role can pass role to the same role, so all three paths cross it: a choke point. Choke points are ranked by the paths through them: one path is medium, two high, three or more critical. Fix it and every path through it is cut. From the choke point, the role can read a crown jewel: an RDS instance or cluster, S3 bucket or DynamoDB table, an admin-bearing IAM principal, or a resource tagged crown-jewel, sensitive or with a data-classification tag. A name alone never makes one. Paths are walked for up to 8 hops from an internet-facing resource. Structural legs, such as runs as role and can read, are accepted from the relationship kaveo stored at scan time. The two permission hops, can assume and can pass role to, are each simulated with the read-only iam:SimulatePrincipalPolicy call; both are allowed, and each result is stored as an observation in the append-only ledger. Three particles walk the three paths and rest at the crown jewel. A fourth branch, the instance role's iam:PassRole to another role, simulates as denied and stops there, so that chain stays hidden. Note 1: toxic-path findings start suppressed; a chain is shown only when every simulated hop is allowed.INTERNET · internet-facingYOUR PERIMETERAWS ACCOUNTiam:PassRolesimulated · deniedchain stays hiddenstored edgeruns as rolecan pass role tocan assumeroleinstance roleSIMULATED · ALLOWEDiam:SimulatePrincipalPolicyeach result stored as an observationroleCHOKE POINT3 PATHS CROSS1 MEDIUM · 2 HIGH3+ CRITICALcan readcrown jewelRDS · S3 · DYNAMODBADMIN IAM · SENSITIVE TAGrole1

  1. Attack paths, checked hop by hop

    Paths from the internet to crown jewels over the IAM and reachability graph, with choke points ranked by how many paths they cut. On a live AWS scan, a toxic-path finding is shown only after each permission hop is simulated with a read-only call and allowed.

  2. An evidence ledger behind every result

    Observations are append-only — a database trigger rejects edits. Each finding, and each AI claim, links to the stored observations behind it.

  3. Compliance mapping, not certification

    Findings roll up onto 10 frameworks, including CIS AWS, PCI DSS, SOC 2, ISO/IEC 27001 and NIST SP 800-53. Export CSV, JSON, a per-control evidence worksheet or a PDF pack for your assessor.

  4. Fixes that are approved, then verified

    Every fix is a saga an admin approves with a typed reason. It runs as a dry run by default. With a separate write role enabled, a supported fix is applied and then checked, in most cases by re-running the finding's own detector.

  5. Native AWS findings, kept distinct

    GuardDuty, Inspector and Security Hub findings are imported, marked native and passed through the same suppression rules as kaveo's own.

  6. Access for agents and pipelines

    An opt-in, read-only MCP server lets your agents query scans, findings and evidence. The CLI returns stable exit codes, so a pipeline can tell a failed gate from an outage.

Outcomes

What changes with kaveo.

A report you can defend

Every finding and every AI claim points back to the stored observation behind it, so an assessor checks the source instead of taking the report's word.

The first fix is the one that matters

Choke points show where one change cuts every attack path through it, so the first ticket you open cuts the most attack paths.

No new data flow to approve

Out of the box, the only outbound traffic is the role assumption and read-only calls to the accounts you connect. There is no vendor data plane to add to your diagrams.

Compared

kaveo and SaaS scanners

Each line on our side is sourced from the docs. The other column describes the general approach, not any one vendor.

Where it runs
kaveoInside your environment, as a Docker Compose stack you operate
SaaS scannersIn the vendor's cloud, which collects your configuration
Where results live
kaveoYour own Postgres database, with row-level security
SaaS scannersThe vendor's platform
Evidence
kaveoEvery finding cites the stored observation that produced it
SaaS scannersVaries — the underlying evidence usually stays with the vendor
AI
kaveoOptional and offline by default — claims must cite stored evidence
SaaS scannersVaries by vendor — runs on the vendor's infrastructure
Isolated networks
kaveoAir-gapped bundle with checksummed images
SaaS scannersNeeds outbound connectivity to the service
Coverage breadth
kaveoDeep on AWS. Azure, GCP and Kubernetes are early
SaaS scannersOften broader multi-cloud coverage today

Rollout

How teams roll out kaveo.

  1. Rev A · Evaluate

    Start the stack

    Set the required secrets, start the Compose stack and explore the seeded, clearly labeled demo scan before you connect anything real.

  2. Rev B · Connect

    Grant read-only access

    Deploy the read-only role with CloudFormation or Terraform in a non-production account, register it and let kaveo verify it can assume the role.

  3. Rev C · Operate

    Tune and schedule

    Review findings and attack paths, record accepted risks as time-boxed waivers, and schedule scans so each run produces a brief of what changed.

  4. Rev D · Extend

    Add accounts and gates

    Connect more accounts, gate CI on the CLI and, only if you choose, deploy the separate write role so approved fixes can be applied and verified.

Who it's for

Built for the teams who have to answer for it.

  • Security engineering

    Findings you can act on without re-proving them.

    Deterministic detectors, attack paths with choke points, and the evidence behind every result in one place.

  • Compliance and audit

    Evidence an assessor will accept.

    Controls map to findings and findings map to stored observations, exported as a per-control evidence worksheet.

  • Cloud and platform engineering

    Least-privilege access and nothing that writes by surprise.

    A read-only role pinned by an ExternalId. Writes need a separate role, admin approval and a verification step.

FAQ

Questions teams ask about kaveo.

The full FAQ in the docs

No. Scanning uses a read-only role with the AWS-managed SecurityAudit and ViewOnlyAccess policies, and its trust policy admits only kaveo's principal presenting your ExternalId. Write access exists only if you deploy a separate remediation role, register it and turn the executor on. Even then, kaveo assumes that role only to apply or roll back a fix an admin has approved, never during a scan.

Into kaveo's own Postgres database, inside your environment. The stock configuration runs the AI provider offline, keeps telemetry in that local database and turns billing off. Hosted AI, Slack, GitHub pull requests, Jira, alert channels, email and the MCP server each stay off until you configure them. If you enable a hosted AI provider, it receives prompts built from your findings and their evidence.

No. Findings come only from deterministic detectors or from imported native AWS findings. A CI contract fails the build if the AI layer imports detector or collector code. Any AI claim whose citations are missing, or do not resolve to a stored observation, is dropped before it is saved. Grounding proves where a claim came from, not that the reading is right, so keep a person on judgment calls.

AWS in depth, across identity, data stores, network, logging, secrets, compute and AI services. Azure, GCP, Kubernetes and GitHub are early — each has one collector and one detector today, and each needs an optional package added to the image. If a credential or provider call fails, the scan fails with the reason. For these providers, kaveo never substitutes demo data for a real account — any synthetic scan is labeled synthetic.

Yes. The air-gapped bundle packages every container image with SHA-256 checksums you verify before loading. With the AI provider offline, or a self-hosted model through the local provider, the only runtime egress is the role assumption and the read-only calls to the accounts you scan. Automatic TLS needs a public certificate authority, so bring your own certificate or terminator.

kaveo works alongside them. It imports Security Hub, GuardDuty and Inspector findings, marks them native so they stay distinct from its own, and runs them through the same suppression rules. On top, it adds its own deterministic detectors, an IAM and reachability graph with attack paths, compliance mapping and an evidence ledger behind every result.

No. The optional patrol drafts a small number of fixes after each scan as proposals and never applies them. Approving, executing or rolling back a fix needs a permission only admins hold, and approval requires a typed reason. Pull requests go to a separate branch and are never merged by kaveo. Without the write role and executor, every fix is a dry run.

Sources

Read the source of every drawing.

Each schematic on this page is drawn from the kaveo documentation, not from a product screen. The pages below are where every label comes from.

All kaveo docs

Use cases

Where teams put kaveo to work.

Related reading

Notes on how kaveo is built.

See kaveo against your architecture.

Book a demoTalk to us