Trust Center

What it may do, and what we have proven

We are pre-launch. We do not have a SOC 2 report, an independent penetration test, or a customer list to show you. What we have is a system you can check, and a straight answer about where the gaps are. That list comes first, because it is the part most vendors move to the end.

What we do not have yet

Every item here is something a security questionnaire will ask for and we would have to answer no. If one of them is a hard requirement for you, it is better that you learn it on this page than three weeks into a procurement cycle.

SOC 2

Not attained. No auditor is engaged and no observation window has started, so no report exists.

Independent penetration test

Booked, not yet performed. We previously published a passing figure from our own harness and withdrew it — the correction is on the security page, and the replacement is a third-party test with a published report.

Public bug bounty

Not open. Report anything you find to security@clearsocapp.com in the meantime.

ISO 27001, HIPAA attestation

Neither held, neither in progress. If a questionnaire asks, the answer is no.

A published disaster-recovery report

The drill has run twice and passed both times. On 29 September 2026 the database was restored in 4 seconds and one tenant-day of events in 10 seconds, against a 60-minute target. The log is internal, so this stays on the list until there is a report you can read.

Independent review of the AI system

None. The controls described here are ours, self-assessed, and covered by our own tests.

A stated retention term for what reaches the AI

Our security architecture says what is sent to Anthropic and that it is not used to train models, both of which we can show you. It does not state how long Anthropic keeps it, because that is their contractual term and we would be repeating it from memory. Ask and we will get it in writing.

A published incident response policy

Written, not published. It commits to acknowledging a critical incident within thirty minutes and there is no staffed rotation behind that, so publishing it would promise more than the response posture on this page. It goes out when the promise is one we can keep.

Published incident history

Not published yet. The status page says so rather than showing an unmeasured green tick.

How ARGUS is constrained

Each of these is a rule in the code rather than a policy we intend to follow.

Critical never runs unattended

Autonomy is set per tenant across four levels. Even at the most permissive one, a Critical incident is always staged for a person — there is no setting that lets it execute on its own. The default level is more conservative still: on its own it may only tag a user as risky, only on low and informational incidents, and stages everything else.

It is rate-limited against itself

Autonomous actions are capped per tenant per hour (ten by default). Past the cap ARGUS stops acting and starts queueing for approval, so a bad detection run cannot become a hundred executed changes. A staged approval escalates if nobody answers it rather than quietly expiring.

The model is optional

Unset the API key and every AI surface falls back to deterministic, rule-based analysis. The product keeps working. That is also the rollback path if you ever want the model out of the loop — it is a configuration change, not a migration.

What actually leaves

One incident and its correlated events go to Anthropic for analysis. Not bulk logs, not mailbox contents, not file bodies. Your data is not used to train third-party models; the privacy policy names every sub-processor and states that plainly.

The record cannot be edited

Every autonomous action is written to an append-only forensic log. Deleting from it is blocked by a database trigger, not by convention — and that log deliberately survives account deletion, so the record of what was done to your environment outlives the account it was done in.

It is not analyzing you here

Ask ARGUS on this site answers from a fixed set of approved statements about the product. It has no access to your environment, runs no model, and says so when a question falls outside what we have published rather than guessing.

Sub-processors

The third parties this platform is configured to use, and specifically what reaches each one. Where we know the region from the endpoint we are connected to, it is named.

Sub-processor	Purpose	What they receive
Railway	Application, PostgreSQL (including security events) and Redis hosting	All platform data at rest and in process.
Amazon S3 AWS us-east-2 (United States)	Encrypted backups	Hourly database snapshots, and a daily archive of ingested security events.
Anthropic	AI incident analysis	One incident and its correlated events. Not bulk logs, not mailbox contents, not files.
Brevo	Transactional email	Recipient address and message content.
Sentry United States	Error monitoring	Stack traces and request metadata.
Honeycomb United States	Application logs, traces and metrics	Log messages and request traces. Some log messages include a user's email address or an IP address.
Microsoft Graph	Ingestion and response actions you authorize	Only what the tenant's granted OAuth scopes permit.
Have I Been Pwned	Dark-web credential exposure checks	The email addresses you ask us to monitor.

Documents and questions

The security architecture write-up is published in full — read it without asking anyone. It is the repository's own copy, embedded at build time rather than duplicated into a folder that would go stale.

Two others are written and deliberately not published. Our incident response policy commits to acknowledging a critical incident within thirty minutes, and there is no staffed rotation behind that yet — publishing a harder promise in a linked document than the one on this page would make it worth less, not more. Our data processing agreement is a contract executed per customer rather than a page to read; ask and we will send the current draft.

Retention, deletion and encryption are covered in detail on the security page, and live component health is on status, where a row that has no probe behind it says so instead of showing green.

Security and trust questions: security@clearsocapp.com. Data protection and DPA requests: privacy@clearsocapp.com. Vulnerability reports go to the first address. There is no staffed rotation behind it yet — response is best-effort while we are pre-launch, which is the honest answer and the reason it is written here rather than left for you to discover.