Middleware SecurityAvailable
Posture for the systems between your services.
Vectasec reads the brokers, gateways, meshes and MCP servers that connect your systems, without changing them, so platform and security teams can see the misconfigurations, service identities and exposure paths in a layer most tools skip.
Hosted control plane — an optional Collector keeps credentials in your network. The fully self-contained deployment is in preview.
- Coverage
- Gateways · brokers · meshes
- Credentials
- Stay in your network (Collector)
- Self-hosting
- Preview
- Detection
- Deterministic rules
Documented: 448 detectors · 39 read-only connectors · 5 frameworks, 30 controls · see the docs
The problem
The integration layer belongs to everyone, so no one.
It carries everything
Brokers, gateways and meshes sit on every request and event, yet rarely appear in a threat model. Defaults like plaintext listeners and brokers with no authorizer survive for years.
Identities nobody inventoried
Service accounts, broker users, API consumers and OAuth clients collect grants with no owner and no rotation, and none of them show up in tooling built for human users.
Silence looks like a pass
When a check cannot read the setting it needs, a quiet report looks exactly like a clean one. The gap only surfaces when something goes wrong.
How it works
Read it, prove it, keep credentials where they are.
Connect read-only
Connectors use list, get and describe calls and never write. On AWS, one cross-account role covers SQS, SNS, EventBridge, MSK and API Gateway. For private systems, a Collector runs the same connectors inside your network and connects outbound only.
Detect with evidence
Deterministic detectors run against what was read, and each finding is committed with the observation it cites. A finding is keyed to rule, resource and connection, so production and staging stay separate and a rescan never reopens one you resolved.
Report gaps as gaps
A denied read becomes a not-assessable finding, never a pass. Compliance controls stay failing or unknown until a person attests, and a live failing finding overrides that attestation.
Chain intact · exit 0
$ vectasec doctor --verify-ledger chain intact
A break · exit non-zero
$ vectasec doctor --verify-ledger
# up to 20 breaks, each with
# finding · observation · reasonRecomputes the per-finding hash chain over stored observations. On a break it lists up to 20, each with its finding, observation and reason, and exits non-zero.
Stations in the drawing
What happens in one scan, from connection to verified evidence. Hover or focus a row to light its station in the drawing.
S1Connect or Collector
Connectors use list, get and describe calls. A Collector runs them inside your network, keeps target credentials there and connects outbound only.
outbound onlyvectasec/run-a-collector
S2Derive identities
Non-human identities, credentials and grants are derived from what was collected (engine-run scans only today). Data classes come from names and labels — payloads are never read.
29 of 39 connector typesvectasec/identities-and-attack-paths
S3Detect
Deterministic rules run against the resource kinds they declare. A detector that raises is recorded and skipped.
448 detectorsvectasec/findings-and-evidence
S4One write transaction
Resources, edges, findings, their observations and compliance state commit together. You see all of a scan's results or none of them.
all or nothingvectasec/how-it-works
S5Verify the ledger
Observations are SHA-256 chained per finding. The check recomputes the chain and exits non-zero on a break.
vectasec doctor --verify-ledgervectasec/findings-and-evidence
Capabilities
What Vectasec builds from what it reads.
Read-only connectors across the layer
Kafka, RabbitMQ, Pulsar, NATS, Kong, Kubernetes with Istio and Linkerd, AWS messaging and API services, Vault, Keycloak, MCP servers and more. Azure and GCP connectors are preview.
Non-human identity inventory
Service accounts, broker users, API consumers, OAuth clients and their grants, derived from collected configuration. Credentials are recorded as metadata, never as values.
Attack paths
Exposed surfaces, wildcard grants and data named like payment, health or secret material are correlated into hop-by-hop chains. Every hop cites a resource from the scan. A path is a correlation, not proof of exploitation.
Discovery of unmonitored middleware
Probes only the hosts and ranges you declare, sends no credentials, refuses public addresses by default, and flags services that no connection is scanning.
Evidence ledger and grounded triage
Observations are hash-chained per finding and the database rejects edits to evidence — the ledger is tamper-evident, and doctor --verify-ledger finds breaks. Optional AI triage must cite a stored observation, and it can raise a finding's urgency but never lower it.
Reports and routing
Export OSCAL, CSV, and CycloneDX SBOM and VEX documents. Route new findings to Slack, Microsoft Teams, Jira, email, a signed webhook or a SIEM.
Outcomes
What changes with Vectasec.
The identities machines use, in one list
The service accounts and broker users Vectasec derives from the systems it scans directly, with their grants and credential metadata, and wildcard and default accounts flagged.
Findings that settle the argument
Each one quotes the value it read, such as a listener mapped to plaintext, so the conversation starts from the fact.
Coverage you can see
Not-assessable findings name what could not be read and which permission would close the gap, so blind spots are on the list too.
Compared
Vectasec and API‑traffic security tools
Each line on our side is sourced from the docs. The other column describes the general approach, not any one vendor.
- What it reads
- VectasecConfiguration and status of brokers, gateways, meshes and MCP servers
- API‑traffic security toolsLive API requests and responses
- In the traffic path
- VectasecNo. It routes no traffic and reads no message payloads
- API‑traffic security toolsUsually inline, or fed mirrored traffic
- Beyond HTTP
- VectasecKafka, RabbitMQ, MQTT brokers, NATS, coordination stores and more
- API‑traffic security toolsPrimarily HTTP APIs
- Service identities
- VectasecDerived from ACLs, broker users, consumers and role bindings
- API‑traffic security toolsSeen through the tokens that appear in traffic
- Runtime behavior
- VectasecSampled at scan time from each system's own APIs — no sensor
- API‑traffic security toolsA continuous view of real requests, including abuse patterns
Rollout
How teams roll out Vectasec.
Rev A · Try
Scan a broken lab
The quick start scans deliberately misconfigured Kafka, RabbitMQ and Redis containers on your own machine, so you see real findings before connecting anything.
Rev B · Connect
Add read-only connections
Start with one system, such as an AWS account through a read-only role in a non-production account, and read what comes back, including the gaps.
Rev C · Extend
Reach private systems
Run a Collector inside your network for systems that only answer from there. Preview the exact payload it would send before you enroll it.
Rev D · Operate
Schedule, route, attest
Set rescan intervals, route new findings to your team's tools, attest to controls with a named scope, and verify the evidence ledger on a schedule.
Who it's for
Built for the teams who have to answer for it.
Platform teams
A consistent view across many brokers, gateways and meshes.
One model and one findings list across every connector, with each finding tied to the connection it came from.
Security and identity
Service identities and their grants in view.
A derived inventory of non-human identities, wildcard grants and default accounts, plus attack paths that cite each hop.
Compliance
Evidence mapped to the frameworks you answer to.
Findings map to PCI DSS 4.0.1, NIS2, DORA, HIPAA and the MCP specification, with attestations and OSCAL export.
FAQ
Questions teams ask about Vectasec.
No. Connectors read configuration and status and do not change configuration or data. On AWS they make List, Get and Describe calls, plus AssumeRole when you give a connection a role. The MCP connector never issues tools/call. Two checks test whether a default account still works: a whoami request as RabbitMQ's guest user and, for Nacos, a login as the default nacos user unless you set credentials. Neither changes configuration or data.
No. It reads configuration. It does not consume messages, sample rows or read values held in caches and key-value stores. Data classification works from resource names, namespaces and labels, so a topic called payments is recorded as named like payment data, not as containing it. A name match alone is only a low-severity inventory finding.
The control plane is hosted today. For a cloud-mode connection, secret fields are stored in a vault, one secret per connection, and merged into memory only at scan time. For systems inside your network, a Collector runs the same connectors there, connects outbound only and keeps credentials local. A fully self-hosted stack exists as a preview and is not yet supported.
Findings with the observation behind each one, resource names and labels, the edges between resources, each target's settings with credentials masked, and scan status. Each observation quotes the setting its rule read, and labels can include internal hostnames and ports. Credentials, message contents and the configuration as a whole stay inside. Redaction runs as the last step before anything is sent, and a preview command prints the exact payload without contacting the control plane.
A finding can prove a control fails, but its absence cannot prove the control is met, because Vectasec sees only the systems it scanned. Evaluation therefore reports controls as failing or unknown. A control passes only when a person attests to it with a stated scope, and a live failing finding always overrides that attestation.
No. Without a model key, triage writes a deterministic summary that quotes the newest evidence, and nothing is sent to a model. With a key, the model sees one finding and its recent observations as untrusted data. Its output must cite those observations, the database refuses to store uncited output, and it can raise a finding's urgency but never lower it.
The Kafka connector cannot yet scan listeners that require SASL or TLS. Sign-in is email and password or Google, with no SAML, OIDC or SCIM. Collector enrollment tokens are created by an operator with database access, not from the console. Collector scans skip enrichment and follow-up steps today: no derived identities or data classes, so no identity, credential or attack-path findings, and no vulnerability-feed lookups, estate correlation or notifications. The Collector is an early release (0.0.1) with no mTLS, unsigned images and no result spool. There is no in-cluster runtime sensor.
Sources
Read the source of every drawing.
Each schematic on this page is drawn from the Vectasec documentation, not from a product screen. The pages below are where every label comes from.
Use cases