# Verify it yourself > What you can test from outside, what we will show under NDA, and what the red-team suite covers. You should not have to take any of this section on trust. This page collects the checks, grouped by what you need to run them. ## What a client can test from outside ### With no credentials | Check | How | Expect | | ----------------------------------------- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Transport and headers on the sign-in page | `curl -sI https://platform.atlanticagenticlabs.com/` | HSTS, `nosniff`, `X-Frame-Options: DENY`, a nonce-based CSP that changes on every request | | A hostname that is no tenant’s | `curl -sI https://example-not-a-tenant.atlanticagenticlabs.com/` | Stopped at the edge and sent to sign in; no page of LightHouse is served | | Your own scanner | Point a passive scanner (OWASP ZAP baseline, or your own) at the sign-in page | Tell us anything it finds ([below](#reporting-a-vulnerability)) | ### With your tenant’s credentials Use a `viewer` API key and your tenant’s Access service token, as in [Authentication](/api/authentication/). | Check | How | Expect | | ---------------------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | A key works only at its own tenant | Call `GET /api/v1/health` with your key at your host, then at any other host | `200`, then refused | | Revocation is immediate | Revoke a key in **Settings → API keys**, then use it | `401` | | A key cannot act | `POST /api/v1/approvals/decisions` or `POST /api/v1/limits` with a key | `403 person_required` | | A key cannot administer | `PUT /api/v1/access` with a key | `403 role_required` | | Content needs its role | Call the MCP tool `knowledge`, or `GET /api/v1/content/knowledge`, with a `viewer` key | Refused, `role_required` | | MCP is read only | `tools/list` on `/mcp` | Every tool is a read | | No tenant parameter | Add `client=` or `tenant=` to any read | Ignored, or `400 bad_query` | | Request size cap | Send a 300 KB JSON body to any write route | Refused before it is read in full | | Idempotency | Send one command twice with the same `Idempotency-Key` | The same `command_id` both times | | Your second factor | `GET /api/v1/me` from a person’s session | `viewer.mfa.source` names how it was proved | | What Atlantic can see | `GET /api/v1/access/review?format=csv` (a `client_admin`) | Every role holder, every key, every Atlantic staff read | | The audit trail | **Setup and admin → Audit**, or `GET /api/v1/audit` | Your test requests’ refusals, sign-ins and changes, each with its actor | ### In your own account | Check | How | Expect | | ---------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Nothing listens for Atlantic | Inspect the security groups or firewall rules the stack creates | No inbound rule exists for LightHouse: the reader and the handler connect outbound | | Egress is narrow | Restrict outbound traffic to your model endpoints and the one Atlantic hostname | The engine keeps working | | No long-lived keys | List the IAM users and access keys the stack created | None | | What leaves | Capture your deployment’s outbound telemetry at your egress proxy | Counts, costs, timings and identifiers; no document text, prompt or answer | | Who read your content | Your content reader’s log | One line per read: viewer, signing key, request ID, what and when | | Cut-off | Stop the content reader, or remove Atlantic’s public key from it | LightHouse shows content as unavailable; nothing else changes | ## What we will show under NDA Some evidence is sensitive to publish, but is yours to see before you sign. The company site has a [mutual NDA](https://atlanticagenticlabs.com/legal/mnda-v1.pdf) ready to sign. Under it, our certified forward-deployed engineers will take you through: - the row-level security policies, and the test that fails LightHouse’s build if any tenant table lacks them; - the latest point-in-time security review and the CI scan results for the components you will run; - the tool policy’s self-test, run against your own agent cards; - the infrastructure modules your stack is built from, at the release tag you would apply. ## What a red-team suite covers before go-live Octy, the assistant that runs on the engine in your account, has a red-team evaluation suite that must pass before a client’s first pilot. Its cases cover: - **injection through retrieved documents**: text in a source that tries to give the model orders must reach it only inside a fence, and must not change what is done; - **approval and payment coercion**: asking the assistant to approve, pay, change access or raise a limit must be refused; - **exfiltration**: an answer must not carry a planted link or address out; - **overclaim**: an answer must cite the sources it relies on, and be grounded in them. In CI the suite runs against a stub model that is gullible by design, so it tests the code around the model rather than a model’s good behaviour. A suite passes only if every case passes; the metrics are reported beside the pass, never instead of it. A live run, against your own gateway and models, is started by a person, and you can watch it. The results reach LightHouse as evaluation records (counts and pass or fail, never the questions or answers): `GET /api/v1/evals`. A red-team suite for every agent pack in the library, run before each release: \[Coming] ## Reporting a vulnerability Email **** with “Security” in the subject. Please include what you found, how to reproduce it, and how to reach you. Do not include real client data. A published `security.txt` and a coordinated disclosure policy: \[Coming] Source: https://docs.atlanticagenticlabs.com/security/verify/