Security
Security answers, in the order a CISO asks them
AI Testing Probe runs as containers in your environment. Only one service calls the model, generated tests run in an isolated runner with no internet and no secrets, and every AI call and human decision is recorded in a hash-chained audit log. This page answers the usual security questions plainly, including what is not available today.
- No AI output becomes a test asset without human approval
- 0 AI calls in CI
- Deploys in your environment. You control what reaches the model.
What data goes to the model?
The model receives only what the current step needs, and only one service, the core worker, can call it.
Sent, by step
- Requirement review: story text, acceptance criteria and the product owner's answers.
- Consistency check: relevant code read with a read-only token, and masked results of restricted queries run through a read-only role on allowed tables and columns.
- Test case generation: the approved story, acceptance criteria, product owner answers and test data.
- Code generation: case steps and the agent's view of the page through allowlisted browser tools.
- Triage and bug drafts: failure details and CI log excerpts, only when no deterministic rule could classify the failure.
Not sent
- Screenshots. They are taken outside the model loop and kept as evidence for reviewers.
- Credentials and write access. Secret fields in agent tool arguments are masked in the record.
- Raw database contents. Queries are single SELECT statements with row and time limits, and results are masked.
- Anything from CI. No model runs in your pipeline.
Personal-data masking in the model gateway (national ID, IBAN, phone, e-mail) is available and must be switched on whenever customer data is processed; pilots can run on synthetic or non-production data.
Where does the model run?
Today the model gateway uses the Anthropic API with Anthropic Claude. Provider-specific code lives only in adapters, behind a swappable model gateway.
The platform does not use customer data for model training or fine-tuning. How the provider retains or uses API data is governed by the provider's commercial terms, which your team should review.
Every call is recorded with model, version, prompt bundle hash, masked input, output, tokens, cost, channel and person.
Model in your own cloud account or tenant: not available today. It is tracked together with other model providers: Azure OpenAI and other model providers Roadmap
Where is the platform deployed?
The platform is installed as containers inside your environment. Your Jira, Xray and Git stay where they are; outputs are written there as issues and pull requests.
No inbound ports are opened beyond the local host. Access to the review portal is arranged inside your network.
What are the network boundaries?
Services are split across separate networks. Most are internal networks with no route to the internet.
Your environment
Internal networks, no internet route
- Test runnerReaches only the application under test and the toolchain. No internet, no secrets, no database access.
- Toolchain workerCompiler, linter and AST guard. Sole writer of merge gate results, which the test runner cannot see. No database credentials.
- Agent browserReaches only the application's web front end. Only the core worker can connect to it.
- DatabasePostgreSQL with append-only audit tables.
Platform services
- Core workerThe only service that holds model keys and write credentials, calls the model and writes to Jira, Xray and Git.
- Core API and review portalPorts bind to 127.0.0.1 only. Portal access is arranged in your network.
- Application under testYour test environment.
Outbound
- Model provider APIcore worker only
- Jira Cloud and Xray Cloudcore worker; separate read and write accounts
- GitHubcore worker writes through a GitHub App; the toolchain reads commits with a read-only token
An automated security check verifies these boundaries after every configuration change:
- published ports
- test runner isolation
- audit log permissions
- secret scanning of the repository
- the read-only data role
- where model keys and write credentials live
- agent browser isolation
- merge gate isolation
- no agents in CI images
Identity and roles
The portal enforces role-based access control with five roles: analyst, product owner, engineer, tester and manager. Each role sees only the actions it may take, and every decision is recorded under the person and role that made it.
Approvals are bound to a content hash: if content changes after approval, it must be reviewed again. API tokens, for example from MCP clients, can submit drafts but cannot approve.
Single sign-on (OIDC or SAML) for the portal is not available today. Portal users sign in with platform accounts. If SSO is a requirement, raise it early so it can be scoped as a pilot condition. Single sign-on (OIDC / SAML) Roadmap
Audit
- Every AI call, tool call, approval and rejection is recorded.
- Audit tables are append-only: the application's database role can insert but cannot update or delete audit events.
- Each event stores the hash of the previous one, computed with SHA-256 over the previous hash and the event's canonical JSON. The chain can be verified from the portal.
- The chain head is also pinned outside the platform, in Jira comments and pull request descriptions.
- The log can be exported as JSON Lines with a SHA-256 checksum file. A full reset exports the log first and stops without deleting anything if the export fails.
Run artefacts are kept on volumes with retention limits. The default retention period for the audit log is being confirmed.
AI-specific risks
- Prompt injection
- Jira content, page snapshots, code, data and CI logs are treated as untrusted. They are passed in labelled data blocks, and instructions inside them are not followed.
- Hallucinated findings
- Every finding must cite evidence, such as a file and line or a query result. The platform re-verifies it without a model and drops findings it cannot confirm.
- Malformed output
- Each call must match a JSON schema. Invalid output is retried a limited number of times, then handed to a human.
- Unsafe generated code
- The model does not write TypeScript. Code is filled into a template with type-checked literals and checked by an AST guard.
- Agent overreach
- The code agent gets only allowlisted browser tools, stays on the application's origin and has a bounded number of tool calls. Tools that run arbitrary code or read files are never given to the model.
- AI in production pipelines
- CI and test images contain no model key, agent or model SDK.
- Unchecked prompt changes
- A prompt or rule change is not merged until its evaluation set has passed against a live model.
Certification
ISO 27001 and SOC 2: not certified today.
The certification plan is being confirmed and will be published here.
Instead of a certificate, this page lists concrete controls you can verify in a pilot.
Regulated-sector paths
- Pilot data
- Pilots can run on synthetic or non-production data.
- Model in your tenant
- Running the model through your own cloud account or tenant is not available today. See "Where does the model run?" above.
- Provider retention
- Data retention and any zero-retention options are set by the model provider's commercial terms. Review them with your legal team before processing customer data.
- Masking
- Personal-data masking in the model gateway (national ID, IBAN, phone, e-mail) is available and must be switched on whenever customer data is processed.
Enterprise deployment
Today the platform is installed with Docker Compose on a single Linux server. Container images are built for both arm64 and amd64.
What you provide
- A Linux server with Docker.
- Network access from the server to the test environment of the application under test.
- Outbound access to the model provider API, Jira Cloud (and Xray Cloud if used) and GitHub.
Recommended CPU, memory and disk sizing is being confirmed.
Images are pinned by digest, CI actions by commit SHA, and lockfiles are required. Static analysis runs on every pull request.
Kubernetes or OpenShift deployment is not available today. If it is a requirement, raise it early so it can be scoped as a pilot condition. Kubernetes / OpenShift deployment Roadmap
Procurement documents
Status of the documents procurement teams usually ask for.
| Document | Status |
|---|---|
| Data processing agreement (DPA) | Being confirmed |
| Sub-processor list | Being confirmed |
| Software bill of materials (SBOM) | Being confirmed |
| Penetration test report | Being confirmed |
| Insurance | Being confirmed |
| Source code escrow | Being confirmed |
A completed security questionnaire is available on request.
Vulnerability disclosure
If you believe you have found a security vulnerability, report it to security@antreklabs.com.
Machine-readable contact details are published in /.well-known/security.txt.
Please do not test against systems you do not own.
Start with one story.
In a 30-minute call we look at your stack and a few of your stories, and tell you honestly whether a pilot fits.