Security Model

Built for engagements you cannot afford to leak.

Pentest engagements can contain credentials, hashes, API keys, vulnerabilities, screenshots, internal hostnames, network details, and exploit evidence. This page explains what AttackCompass stores, what Client mode protects, what remains server-readable, what Ask transmits, and how deletion and export work.

Operator controlled. No autonomous exploitation. Transparent data flows. Exportable engagement data.

What this model is answering

The objection is simple: operators will not put client credentials, findings, hashes, screenshots, and internal network data into a black-box SaaS. AttackCompass is designed to reduce how much sensitive engagement data the server can access, make AI context explicit, keep execution operator-controlled, and document residual risk instead of hiding it.

Client mode can keep secrets offline to the server

When workspace locking is enabled, passwords, hashes, notes, and other protected values are encrypted in the browser or local proxy before upload. AttackCompass does not receive the Client-mode workspace passphrase.

Evidence is encrypted at rest

Screenshots stored as media assets are encrypted at rest with AES-256-GCM using a per-workspace key.

Ask is explicit and deployment-configured

Ask AttackCompass sends the question, selected workflow-card excerpts, and recommendation context to the Ollama endpoint configured by the deployment operator. There is no hidden autonomous testing or attack execution.

Deletion removes workspace records

Deleting a workspace hard-deletes its database records and associated media files.

Data classes

Account data and engagement data are different.

AttackCompass separates control-plane account data from engagement content. The security model is primarily about minimizing unnecessary plaintext access to the second category.

Account / control plane

  • Account identity and authentication state (via Auth0)
  • Subscription and entitlement state (via Paddle as merchant of record)
  • Workspace metadata such as names, membership, and sharing mode
  • Billing consent records when a paid plan is chosen
  • Product analytics events only after consent, when enabled

Engagement data

  • Scope, hosts, services, and route context
  • Credentials, hashes, and related secrets
  • Findings, notes, objectives, and sessions
  • Screenshots and other engagement media
  • Workflow progress, recommendations context, and activity timeline entries
  • Report content and export artifacts

Data flow

Know where engagement data moves.

The diagram below names processors, encryption boundaries, and the optional Ask path. It is intentionally specific. If a field is server-readable, this page says so.

Operator

You record scope, hosts, services, credentials, findings, notes, evidence, and workflow progress while running your own tools.

Browser or local proxy

In Client mode with workspace locking enabled, protected values are encrypted before they leave the device. Supported IPv4 identifiers can be replaced with projected labels.

AttackCompass application

The authenticated app stores workspace state, serves recommendations, handles report workflows, and returns redacted credential fields where implemented.

Optional Ask path

Only if you use Ask: the question plus selected card and recommendation context goes to the deployment's configured Ollama endpoint.

Storage

Engagement records and media live in AttackCompass storage. Screenshots use per-workspace AES-256-GCM at rest. Many narrative fields remain server-readable.

Data moves from the operator through the browser or local proxy into the AttackCompass application, then into storage. An optional Ask path can send selected context to the configured Ollama endpoint.
AttackCompass data classes, processors, protection, and server readability
Data classExamplesWhere processedProtectionServer can read
Account / control planeEmail/login identity, subscription, workspace membership, billing consentAuth0, Paddle, AttackCompass appAccess-controlled account systems; not Client-mode encryptedYes
Protected Client-mode secretsCredential passwords, hashes, and other locked protected valuesEncrypted in browser or local proxy before uploadClient-side encryption; passphrase not sent to AttackCompassNo plaintext when locking is enabled
Projected network identifiersSupported IPv4 addresses and octet-aligned CIDRs (/8, /16, /24, /32)Client mode projection before or at uploadReplaced with projected labels where supportedProjected labels only for supported fields
Engagement narrativeUsernames, domains, hostnames, ports, findings, notes, metadataAttackCompass application and storageAccess control and workspace membership; not field-encryptedYes
Media library screenshotsScreenshots and engagement media assetsAttackCompass storageAES-256-GCM at rest with a per-workspace key (server-decryptable)Yes, after server-side decryption
Ask contextQuestion, selected workflow-card excerpts, recommendation contextConfigured Ollama endpoint for the deploymentSent only when Ask is used; locality depends on operator configVisible to the configured Ollama endpoint

Modes

Lab mode and Client mode are not the same security posture.

Choose the mode that matches the engagement. Lab mode optimizes for practice and import workflows. Client mode adds workspace locking and projection controls for sensitive client work.

Lab mode versus Client mode security differences
TopicLab modeClient mode
PurposeLab and practice workflows where plaintext engagement detail is acceptable for the environment.Client engagements where reducing plaintext secrets and supported network identifiers on the server matters.
Scan importNmap XML and OpenVAS XML can populate hosts and services.Scan import is unavailable. After unlocking, projected hosts are added through the UI or local proxy.
Credential passwords and hashesStored according to Lab-mode handling; client-side secret encryption applies in Client mode with locking enabled.With workspace locking enabled, encrypted in the browser or local proxy before upload.
IPv4 identifiersRecorded as entered.Supported IPv4 fields and octet-aligned IPv4 CIDRs (/8, /16, /24, /32) can be replaced with projected labels.
PassphraseNo Client-mode workspace passphrase.AttackCompass does not receive the Client-mode workspace passphrase.
Still server-readableEngagement narrative and inventory fields stored by the workspace.Usernames, domains, hostnames, ports, metadata, findings, and other engagement narrative remain server-readable.

Client-side protection

Keep secrets unreadable to the server when locking is on.

Optional Client mode encrypts credential passwords and hashes in the browser or local proxy before upload. AttackCompass does not receive the Client-mode workspace passphrase. Supported IPv4 fields can be projected so the server stores labels instead of the original addresses.

Encrypted before upload in Client mode

  • Credential passwords
  • Credential hashes
  • Other workspace-locked protected values such as notes covered by Client-mode protection

Projected where supported in Client mode

  • Supported IPv4 address fields
  • Octet-aligned IPv4 CIDRs: /8, /16, /24, and /32

Remain server-readable

  • Usernames
  • Domains and hostnames
  • Ports
  • Findings and engagement narrative
  • Metadata and other non-protected fields

Residual exposure

The server can still read engagement narrative.

Client mode is not a zero-knowledge workspace. Usernames, domains, hostnames, ports, metadata, findings, notes outside protected fields, and other engagement narrative remain server-readable. Media encryption is server-decryptable so the product can render evidence in the authenticated app.

Practical rule: if a field would identify the client environment even without a password, assume the server can store and read it unless this page lists that field as Client-mode protected or projected.

Evidence

Your evidence is encrypted at rest.

Screenshots stored as media assets are encrypted at rest with AES-256-GCM using a per-workspace key. That encryption protects storage media; the application can decrypt those assets for authorized workspace access.

Credentials

Credential handling is field-specific, not absolute.

AttackCompass redacts and sanitizes in specific product surfaces. Those controls are real, but they are not a blanket promise that every API response is secret-free.

List and situation responses

Credential-list and situation responses omit password and hash values.

Report workflow

The report workflow does not automatically include credential inventory rows. Saved report content is sanitized for recognized secret patterns.

Agent API qualification

Treat API consumers as privileged and scope tokens carefully. Report JSON can include Lab-mode credential rows for authorized API access.

Lab vs Client

Credentials are not always encrypted. Lab mode differs from Client mode. Use Client mode with workspace locking when client secrets must not be stored in plaintext.

Ask AttackCompass

Control what AI receives.

Ask is an optional assistance path. It does not turn AttackCompass into an autonomous hacking platform, and it should never be described as a hidden outbound data vacuum.

What is sent

Ask AttackCompass sends the operator's question, selected workflow-card excerpts, and recommendation context.

Where it goes

That payload is sent to the Ollama endpoint configured by the deployment operator. Locality is deployment-dependent. Describe Ask as local only when production configuration pins and verifies a loopback endpoint.

What Ask is not

Ask is not autonomous security testing. AttackCompass does not silently run attack tools because you asked a question.

Training claims

This page does not claim that engagement data is never used to train models. Publish that statement only after every inference processor, retention setting, provider term, and internal data-use policy is documented.

Integrations

Agent API and local proxy stay under your control.

AttackCompass can receive state updates from external agents or workers. Execution remains outside the web product unless you connect something that runs commands.

Authenticated API

External agents or workers can update engagement state through the authenticated Agent API using an account token. The web product itself does not autonomously execute attack tools.

Local proxy in Client mode

After unlocking Client mode, projected hosts can be added through the unlocked UI or a local proxy. The proxy path exists so operators can keep Client-mode entry workflows aligned with projected identifiers.

Privilege boundary

An Agent API token is powerful. Anyone with a valid token can write engagement state the API accepts. Protect tokens like credentials, rotate on exposure, and do not embed them in untrusted automation.

Execution model

Decision support and execution intelligence — not autonomous exploitation.

Security buyers often conflate engagement software with autonomous attack platforms. AttackCompass is built for authorized operators who want ranked next actions, durable context, and report-ready evidence while keeping every offensive action under human control.

  • Recommendations are deterministic over recorded engagement evidence and state, not open-ended model improvisation.
  • Workflow cards provide operator-controlled instructions, copyable commands, prerequisites, and success/failure guidance.
  • You choose and run every attack action in your own environment.
  • The web product does not autonomously execute attack tools.
  • External execution, if used, happens in agents or workers you control and connect through the authenticated API.

Sharing

Workspace sharing is viewer/editor access.

Collaboration exists at the workspace level. It is not marketed here as enterprise RBAC, organization administration, or a compliance-grade audit trail.

  • Workspaces can be shared as read-only or read/write.
  • Treat sharing as workspace viewer/editor access, not enterprise team administration.
  • Anyone with access can see server-readable engagement narrative for that workspace.
  • Client-mode protected secrets remain unreadable without the workspace passphrase on the client.

Activity inside an engagement is available as an engagement activity timeline, not as a comprehensive security audit log.

Deletion

Delete the engagement when you are done.

Deleting a workspace hard-deletes its database records and associated media files.

Workspace records

Workspace database records are hard-deleted on deletion request.

Associated media

Associated media files are removed with the workspace deletion path.

Export

Export your report when you need it.

Take the finished report with you as PDF or Markdown, and print from the generated PDF.

Report PDF

PDF export produces the complete rendered report.

Markdown content export

Markdown export covers report content for reuse outside AttackCompass. Layout-only pages are omitted; media references are retained.

Print

Print uses the generated PDF.

Account plane

Authentication, billing, and analytics processors.

Engagement security sits on top of ordinary SaaS account plumbing. These processors handle identity, commerce, and optional analytics — not a substitute for Client-mode field protection.

Account and supporting processors
ProcessorRole
Auth0Authentication and account identity for app login and signup.
PaddleMerchant of record for checkout, tax, invoices, cancellation, and refunds when you purchase.
AttackCompass application storageEngagement workspace records, media assets, report content, and entitlement mapping.
Configured Ollama endpointOptional Ask inference target chosen by the deployment operator. Not contacted unless Ask is used.
PostHog Cloud EUOptional product analytics for the public site/app only after consent and governance controls allow it. Not an engagement-data processor for credentials or findings.

Application traffic to AttackCompass is served over HTTPS. The field-level model above is the source of truth for what the server can read.

Contact

Report security issues directly.

If you believe you have found a vulnerability in AttackCompass or this website, please use responsible disclosure rather than public exploit detail.

Next step

Read the model. Then try it on an authorized engagement.

Start with the sample engagement, or use AttackCompass on your own approved pentest after you understand what Client mode protects and what remains server-readable.

Operator controlled. No autonomous exploitation. Transparent data flows. Exportable engagement data.