Skip to content
Architecture

How it actually works.

Four diagrams: the data pipeline from endpoint to response, the AI attack path we defend, the trust boundary, and why a read-only sensor and a separate response channel are both true.

Architects should not have to reconstruct our architecture from paragraphs. Here are the four diagrams that matter — the data pipeline, the enterprise AI attack path we defend against, the trust boundary, and the separation between observation and enforcement.

1 · Platform data pipeline

Endpoint to response. The sensor is read-only; secrets are masked and command lines scrubbed before anything leaves the endpoint; classification can run on an in-VPC model; and every finding is scored, attributed and routed to your SIEM/SOAR and ticketing.

TLS 1.2+EndpointWindows / Linux / macOSSensor (read-only)read-only · eBPF on LinuxCollectormask secrets · scrubcommand linesClassificationheuristics + in-VPC modelRisk enginescore · attribute ·knowledge basePolicy engineRBAC · approvals · auditSIEM / SOAR · Jira · Slack+ authorised responsechannel
Endpoint → sensor → collector → classification → risk → policy → response

2 · Enterprise AI attack path

What we test and defend against. Modern AI systems chain an app, a retrieval layer, a vector store, an agent, and MCP tool servers — each hop is an attack surface. The red callouts are the failure modes our Full AI Red Team and continuous testing target.

User / employeeAI applicationRAG retrievalVector DBAgentMCP serverTool → enterprise systemIndirect promptinjection viaretrieved contentTool poisoning ·confused deputyExcessive agency ·over-scoped tools
User → AI app → RAG → vector DB → agent → MCP → enterprise system, with the AI-specific failure modes

3 · Trust boundary

What stays, what leaves, what's encrypted. Raw files and secret values never leave the endpoint. Only masked metadata crosses the wire over TLS. Console data is encrypted at rest — or, with the in-VPC option, never leaves your AWS account at all.

ON ENDPOINTIN TRANSITCONSOLETLSRaw files & secretsNEVER leave theendpointSensormasks secrets ·scrubs cmdlinesMetadata only(no values, nocontents)Risk scores & auditencrypted at restYour AWS accountIn-VPC optionzero egress
On endpoint (raw stays) → in transit (metadata only) → console (encrypted; in-VPC option = zero egress)

4 · Response architecture

The boundary CISOs ask about. Observation and response are separate by design — the discovery sensor cannot act. Today, response runs through the content-DLP policy engine, remote-pause and device revocation (a stolen/rogue device is cut off server-side and can't re-enroll), device attestation against the published sensor releases, and your SIEM/SOAR and ticketing — all operator-authorised. Deeper endpoint enforcement (killing a rogue agent process, inline browser DLP that blocks a prompt before it sends) is on the roadmap and will run through that same separate, opt-in channel — so a read-only sensor and a real response path stay separate, without contradiction.

OBSERVE (READ-ONLY)DECIDEACT (AUTHORISED)findingsoperator-approvedDiscovery sensorread-only · cannotactRisk enginescore & prioritisePolicy enginewho may act, on whatSeparate authorised channelResponseDLP · pause · revokekill-switch: roadmap
Observe (read-only sensor) → decide (risk + policy engine) → act (separate authorised response channel)
Want the deployment topology? Single-tenant managed vs fully in-VPC, HA, scaling limits and DR are covered in the sensor deployment guide — request documentation, or see the Trust Center.