Skip to content

Security that stays inside your perimeter.

A 30-second silent tour of three layers. Agent layer: AI agents call tools on their own, and some instructions are poisoned — Aegis checks each tool call at a gateway before it runs. Integration layer: service accounts in your middleware often have no clear owner — Vectasec maps and scores them with read-only connectors. Cloud layer: scanners raise many alerts without proof — kaveo traces the attack path, and a fix an admin approves is verified by a targeted re-scan. It closes on the line “Security you can prove”, with the three layers connected to the kinds of tools teams already run.

The products

Contain at the boundary.

kaveo and Aegis run inside your perimeter. Vectasec’s Collector keeps credentials in your network — its control plane is hosted on Supabase, outside it.

Three more layers in development

How ZHASK products contain at the boundaryCloud accounts, middleware and agent tool calls sit outside a dashed perimeter. kaveo reads cloud accounts, Vectasec reads middleware and Aegis sits in the path of agent tool calls. Each branch crosses the perimeter inward to the product, which produces findings, evidence and an audit log. kaveo and Aegis run inside your perimeter, so their artifacts stay inside it. Vectasec keeps credentials in your network through a Collector — its control plane is hosted on Supabase, outside your network, and that is where its findings and evidence are stored.YOUR PERIMETERCLOUD ACCOUNTSMIDDLEWAREAGENT TOOL CALLSZHASK DETECTIONLEAST-PRIVILEGE ACCESSFINDINGSEVIDENCEAUDIT LOGSTORED EVIDENCE BEHIND EVERY FINDINGHow ZHASK products contain at the boundaryCloud accounts, middleware and agent tool calls sit outside a dashed perimeter. kaveo reads cloud accounts, Vectasec reads middleware and Aegis sits in the path of agent tool calls. Each branch crosses the perimeter inward to the product, which produces findings, evidence and an audit log. kaveo and Aegis run inside your perimeter, so their artifacts stay inside it. Vectasec keeps credentials in your network through a Collector — its control plane is hosted on Supabase, outside your network, and that is where its findings and evidence are stored.YOUR PERIMETERCLOUDACCOUNTSMIDDLEWAREAGENTTOOL CALLSZHASK DETECTIONLEAST-PRIVILEGE ACCESSFINDINGSEVIDENCEAUDIT LOGSTORED EVIDENCEBEHIND EVERY FINDING

Who this is for

Built for teams that have to control what leaves.

If your obligations or your network limit what a vendor can see, that constraint shapes the product. kaveo and Aegis run in your own environment. Vectasec keeps credentials in your network through a Collector and documents exactly what it sends to its hosted control plane.

Regulated industriesBanks, healthcare, insurers, and public sector teamsMeet data-residency and audit obligations with read-only access, self-hosted posture management and evidence an auditor can check.Cloud security tools that require sending config and logs to a vendor SaaSAuditors asking for evidence, not dashboard screenshotsVendor reviews stalling on data-processing agreementsRead the use case
Air-gapped environmentsDefense, critical infrastructure, and sovereign-cloud operatorsRun posture management in isolated networks where the only egress is role assumption and read-only calls to the AWS accounts you scan.SaaS-only security tools that assume outbound connectivityManual spreadsheet audits standing in for continuous postureUpdate channels that violate isolation requirementsRead the use case
AI agents in productionPlatform, security and AI teams connecting agents to internal toolsPut a gateway between your AI agents and your MCP servers that checks who is calling, decides what each caller may run and records every decision, without changing your servers.Any agent that can reach an MCP server can call every tool it exposesA tool definition can change after you reviewed itNo reliable record of which caller ran which tool, with what outcomeRead the use case

Platform layers

Six layers. One trust model.

Three layers ship today — three are in development and will be named when they ship, not before. Each one is built to the same rules: least-privilege access, evidence behind every result, and every outbound flow documented.

01 / 04Cloud posture

Use the left and right arrow keys to move between layers.
kaveoAvailable

Cloud Security Posture Management

Finds misconfigurations across AWS accounts for teams that can't ship telemetry to a vendor cloud. Runs in your own environment and scans through a read-only role; every finding links the stored evidence that produced it.

Vendor egress
None by default
Scan access
Read-only role
Deployment
Your own environment
How kaveo works
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
VectasecAvailable

Middleware Security

Reads the connective layer most tools ignore — API gateways, message brokers, service meshes and MCP servers. Finds wildcard grants, default credentials and exposed data paths, with read-only access and a Collector that keeps credentials in your network.

Coverage
Gateways · brokers · meshes
Credentials
Stay in your network (Collector)
Self-hosting
Preview
How Vectasec works
Two boundaries, one gatePlan of a Vectasec Collector deployment. Inside your perimeter, a Collector reads four kinds of system with read calls only: Kafka and RabbitMQ brokers, whose message contents are never read; Kong, an API gateway; Istio and Linkerd, service meshes; and MCP servers, where it calls tools/list and never tools/call. The credentials for those systems stay with the Collector, referenced from a local target list as environment variables. One outbound line leaves through a single gate in the perimeter: it carries findings and their observations, resource metadata, edges and each target's config with credentials redacted, and redaction runs last before anything leaves. Two lanes stop inside the gate: credentials stay, and the raw configuration the detectors read stays. The outbound line reaches the engine and worker, which the operator runs together with the console, outside your network today. Beside them sits the hosted control plane, a Supabase project that holds only the database, the evidence ledger, the vault and auth; the engine and worker write to it. Separately, your AWS account is read by the worker through one cross-account read-only role covering SQS, SNS, EventBridge, MSK and API Gateway. Beside the engine, worker and console, a self-hosted stack is drawn as a phantom: a preview whose configuration validates but which has never been booted. Flag 1: scans a Collector runs skip identity derivation and the follow-up steps today.YOUR PERIMETERCONTROL PLANE · HOSTED (SUPABASE)RUN BY THE OPERATORYOUR AWS ACCOUNTCREDENTIALS STAYRAW CONFIG STAYSKafka · RabbitMQBROKERSmessages · never readKongAPI GATEWAYIstio · LinkerdSERVICE MESHMCP server · tools/listNEVER tools/callREAD CALLS ONLYCollectorCREDENTIALS STAY HERElocal targets + envLEAVES · findings + observationsresource metadata · edges · redacted config1collector-run scans skip identity derivationand the follow-up steps todaydatabase · evidence ledgerVAULT · AUTHOUTSIDE YOUR NETWORK TODAYengine + workerconsoleSelf-hosted stack · PREVIEWCONFIG VALIDATED, NEVER BOOTEDSQS · SNS · EventBridge · MSK · API GatewayLIST · GET · DESCRIBEONE CROSS-ACCOUNT READ-ONLY ROLETwo boundaries, one gatePlan of a Vectasec Collector deployment. Inside your perimeter, a Collector reads four kinds of system with read calls only: Kafka and RabbitMQ brokers, whose message contents are never read; Kong, an API gateway; Istio and Linkerd, service meshes; and MCP servers, where it calls tools/list and never tools/call. The credentials for those systems stay with the Collector, referenced from a local target list as environment variables. One outbound line leaves through a single gate in the perimeter: it carries findings and their observations, resource metadata, edges and each target's config with credentials redacted, and redaction runs last before anything leaves. Two lanes stop inside the gate: credentials stay, and the raw configuration the detectors read stays. The outbound line reaches the engine and worker, which the operator runs together with the console, outside your network today. Beside them sits the hosted control plane, a Supabase project that holds only the database, the evidence ledger, the vault and auth; the engine and worker write to it. Separately, your AWS account is read by the worker through one cross-account read-only role covering SQS, SNS, EventBridge, MSK and API Gateway. Beside the engine, worker and console, a self-hosted stack is drawn as a phantom: a preview whose configuration validates but which has never been booted. Flag 1: scans a Collector runs skip identity derivation and the follow-up steps today.YOUR PERIMETERRUN BY OPERATORCONTROL PLANE · HOSTEDYOUR AWS ACCOUNTCREDENTIALSstayRAW CONFIGstaysKafka · RabbitMQBROKERSmessages · never readKongAPI GATEWAYIstio · LinkerdSERVICE MESHMCP server · tools/listNEVER tools/callCollectorCREDENTIALS STAY HERElocal targets + env1LEAVES · findings + observationsmetadata, edges, redacted configOUTSIDE YOURNETWORK TODAYengine + workerconsoleSelf-hosted stack · PREVIEWNEVER BOOTEDdatabase · evidence ledgerSUPABASE · VAULT · AUTHONE CROSS-ACCOUNT READ-ONLY ROLESQS · SNS · EventBridgeMSK · API GATEWAY
AegisAvailable

MCP Gateway Security

Sits in front of the MCP servers your agents call. Authenticates and authorizes every tool call, filters the failure modes specific to tool use, and writes every decision to a hash-chained audit log.

Policy
Allow, deny or approve per tool
Tool definitions
Pinned — changes quarantined
Audit log
Hash-chained
How Aegis works
A refused call never reaches your serverPlan of Aegis, an MCP gateway, drawn inside your perimeter. Three agents, each an MCP client, sit outside; the perimeter has one opening, the identity gate, where every call must carry a valid JWT. Inside, three nested fences are later and later checks: 02 policy, meaning the kill-switch and role-based access control; 03 the approval hold; 04 schema validation and the threat gate for injection patterns, egress DLP and tool pins. Your MCP servers sit in the core and stay where they are. Five calls enter. The first has no valid token and stops at the gate with HTTP 401; it is not written to the audit log. The second has no matching allow policy and stops at fence 02 with −32003. The third matches an approve policy and is held at fence 03 with −32061 until an operator decides. The fourth carries an injection pattern and is blocked at fence 04 with −32051. The fifth passes every check and reaches your servers, allow, code 0; responses are scanned on return and secrets and PII are redacted as [REDACTED:KIND]. Each decision after the gate is written as one row of the audit log, an HMAC-SHA256 chain in which every row's tag is computed from the key, the previous tag and the row, so an edited row breaks the chain. Cheap checks run first and the forward runs last, so a refused call never reaches your server. The drawing is simplified: 5 of the 16 pipeline stages are shown, and rate-limit and quota refusals are not audited.your servers stay where they areAegis — one gateway in front of your servers02 POLICY · KILL-SWITCH · RBAC03 APPROVAL · OPERATOR HOLD04 SCHEMA · INJECTION · EGRESS DLP · PINSYOUR MCP SERVERSMCP serverMCP serverMCP serverRESPONSES SCANNED ON RETURNsecrets, PII → [REDACTED:KIND]1simplified: 5 of 16 stages shownYOUR PERIMETER01 IDENTITY · JWTagentMCP CLIENTagentMCP CLIENTagentMCP CLIENT401no valid token ·not written tothe audit log−32003no matchingallow−32061held · awaitsan operator−32051injectionpatternallow · 0AUDIT LOG · HMAC-SHA256 CHAINtag = HMAC(key, previous tag ‖ row)2rate-limit and quota refusals: not auditedseq nallow0seq n+1block−32051seq n+2deny−32061seq n+3deny−32003nextA refused call never reaches your serverPlan of Aegis, an MCP gateway, drawn inside your perimeter. Three agents, each an MCP client, sit outside; the perimeter has one opening, the identity gate, where every call must carry a valid JWT. Inside, three nested fences are later and later checks: 02 policy, meaning the kill-switch and role-based access control; 03 the approval hold; 04 schema validation and the threat gate for injection patterns, egress DLP and tool pins. Your MCP servers sit in the core and stay where they are. Five calls enter. The first has no valid token and stops at the gate with HTTP 401; it is not written to the audit log. The second has no matching allow policy and stops at fence 02 with −32003. The third matches an approve policy and is held at fence 03 with −32061 until an operator decides. The fourth carries an injection pattern and is blocked at fence 04 with −32051. The fifth passes every check and reaches your servers, allow, code 0; responses are scanned on return and secrets and PII are redacted as [REDACTED:KIND]. Each decision after the gate is written as one row of the audit log, an HMAC-SHA256 chain in which every row's tag is computed from the key, the previous tag and the row, so an edited row breaks the chain. Cheap checks run first and the forward runs last, so a refused call never reaches your server. The drawing is simplified: 5 of the 16 pipeline stages are shown, and rate-limit and quota refusals are not audited.agentMCP CLIENTagentMCP CLIENTagentMCP CLIENT02 POLICY · RBAC03 APPROVAL HOLD04 SCHEMA · THREATYOUR MCP SERVERSMCP serverMCP serverMCP serverRESPONSES SCANNED:secrets, PII →[REDACTED:KIND]01 IDENTITY · JWTYOUR PERIMETER401no valid token ·not in the audit log−32003no matching allow−32061held · awaitsan operator−32051injection patternallow · 0AUDIT LOG ·HMAC-SHA256 CHAINtag = HMAC(key,previous tag ‖ row)seq nallow0seq n+1block−32051seq n+2deny−32061seq n+3deny−32003next1simplified: 5 of16 stages shown2rate-limit, quotarefusals: not audited
Three more layersIn development

Unannounced layers

Three layers are in development. We name one when it ships, not before — no roadmap theater and no pre-announced capability you can't verify today. What we will commit to now is the architecture every one of them inherits.

Trust model
Shared
Data egress
Documented per product
Availability
Waitlist

Committed on day one

Least-privilege accessCommitted for every new layerCommitted
Every outbound flow documentedCommitted for every new layerCommitted
Evidence-backed findingsCommitted for every new layerCommitted
Names, scope, pricingAnnounced at shipTBD

Join the waitlist and we'll write once, when a layer ships.

Anatomy of a finding

A finding is a claim plus its evidence.

Every kaveo finding comes from a deterministic rule and links the stored observation behind it, recorded in an append-only ledger with a hash of what the read returned. An assessor checks the source instead of taking the report’s word.

How kaveo works
Illustration · how a kaveo finding is builtNot a product screen
Open a layer to see what it stores.Drawn from the kaveo evidence and grounded AI docs

Connect to what you already run.

kaveo reads your cloud accounts, Vectasec reads the middleware between your services, and Aegis sits in front of your MCP servers. All three report into the tools your team already watches.

Connectors are read-only. Integrations stay off until you configure them, and nothing is sent anywhere you have not set up.

  • AWS
  • Azure
  • GCP
  • Kubernetes
  • GitHub
kaveoread-only roleVectasecCollectorAegisMCP gateway
ZHASKYour perimeter
AI agents
  • MCP server
  • MCP server
  • MCP server
Evidence ledger
  • Slack
  • Webhook
  • SIEM · OCSF

Scroll sideways to see the full map

kaveo architecture

The mechanism is the trust signal.

kaveo has no vendor data plane and no outbound tunnel. Diff the trust policy before you deploy anything — the shape below is the role you deploy.

The trust-policy shape of the kaveo-readonly role
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "<kaveo-principal-arn>" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "<your-external-id, 8+ chars>"
      }
    }
  }]
}
Principal
Trusts only the principal you pass.
Condition
Requires a matching sts:ExternalId of at least 8 characters.
Attached policies
The AWS-managed read-only SecurityAudit plus job-function/ViewOnlyAccess.
MaxSessionDuration 3600
Sessions last at most one hour and are named kaveo-scan in CloudTrail.

Trust center

Our posture, stated plainly.

SOC 2 Type II is in progress. ISO 27001 is not yet pursued. We publish what we hold, what we’re working toward, and how to reach us when you find something wrong.

Visit the Trust Centersecurity.txtDisclosure policy
SOC 2 Type IIIn progressISO 27001Not yet pursuedResponsible disclosure48h first response

Research

Notes from the build.

All posts
2026-07-08 · 7 min readWhy read-only is a feature, not a limitationWrite access is how security tools become incident vectors. What we gained by refusing it — and what it cost us.2026-06-19 · 8 min readMiddleware is the layer everyone forgetsYour gateways, brokers, and meshes route everything and appear in no threat model. A tour of the misconfigurations worth checking first.2026-05-27 · 6 min readEvidence or it didn't happenA finding without the API call that produced it is an opinion. How kaveo records, links, and cites its evidence.

See your perimeter the way we do.

A 30-minute walkthrough of kaveo, Vectasec or Aegis against your architecture. No deck-only demos.

Book a demoTalk to us