SA-APEX · control standard

Why client data changes everything.

A penetration test contains exactly what an attacker wants: source code, credentials, architecture, weaknesses, exploit paths, screenshots, logs and business context. Candidates have to prove that all of it stays inside approved, isolated systems — and then prove it again under an adversarial test.

Default deny

No client information enters an AI system unless the engagement authorization, data classification, model deployment, provider terms, retention behaviour, region, logging path and downstream tool access are all approved for that data class.

Convenience is not an approval. “It was faster” is not a control.

Classification

Five classes, and a default destination for each.

Data classes and permitted destinations
ClassExamplesDefault AI destination
PublicPublished domains, public source, public documentation.Approved enterprise or private model. A public model only where company policy explicitly allows it.
InternalGeneric methods, sanitized templates, non-client operational notes.Approved enterprise tenant with contractual controls.
Client confidentialPrivate route onlyArchitecture, code, findings, screenshots, logs, asset names.Security Arsenal-controlled or client-approved private deployment. No consumer or public endpoint.
RestrictedPrivate route onlyCredentials, tokens, PII and PHI, private keys, production data, regulated records.Prefer no model ingestion at all. If essential: isolated approved deployment, minimized, encrypted, audited, explicitly authorized.
ProhibitedBlocked and alertedData barred by contract or law, another client’s data, unapproved secrets, exam answer material.Never submitted. Blocked and alerted.

A candidate is scored on whether the classification is enforced by their system, not on whether they can recite the table.

Required controls

Eleven controls, each of which has to actually run.

  • Included:Per-client tenant and encryption context. No shared vector index and no shared prompt cache across clients.
  • Included:Provider and model allowlist enforced in code, not merely written down in a policy document.
  • Included:Outbound content inspection for secrets, identifiers, regulated fields, large source blocks and prohibited file types.
  • Included:Context minimisation — send the smallest relevant slice, with pseudonyms or structural substitutes where they work.
  • Included:A contract and configuration record covering training use, retention, human review, subprocessors, region, deletion and incident notification.
  • Included:No model-training use of client content unless a separate, explicit client agreement authorizes it.
  • Included:Encryption in transit and at rest, per-tenant keys where feasible, and secrets retrieved just in time so they never enter a prompt.
  • Included:A complete audit of user, client, engagement, model and version, policy decision, tool invocation, source references and output disposition.
  • Included:Retention schedules for prompts, outputs, embeddings, traces, artifacts and backups, with a deletion workflow that is verified rather than assumed.
  • Included:An emergency provider disable switch and a client-specific quarantine capability.
  • Included:A leakage-response playbook covering containment, provider requests, token rotation, evidence preservation, notification and what changed afterwards.

Leakage tests

Six adversarial tests every candidate builds and passes.

These are not tick-boxes. Each one is an attack against the candidate’s own system, and each one has to fail to succeed.

Test 01

Cross-tenant retrieval

Client B queries must never retrieve Client A content, including semantic near-matches.

Test 02

Canary

Seeded unique client strings trigger blocking and are absent from any downstream log not authorized to hold them.

Test 03

Prompt-injection exfiltration

Malicious repository content cannot redirect the agent into transmitting secrets.

Test 04

Tool boundary

The agent cannot read paths, networks, credentials or repositories beyond the assigned scope.

Test 05

Retention verification

Deleting an engagement removes live prompt, output and retrieval artifacts to policy, and records the deletion event.

Test 06

Provider failover

The system fails closed rather than silently routing restricted data to an unapproved model.

Non-compensable

A confirmed leak of protected data during the exam ends the attempt. So does a bypassed gateway and an unapproved provider route. There is no score high enough elsewhere to carry a candidate past a client-data failure, because there is no client who would accept that trade.

What this is really about

The engineer stays accountable for what the model touched.

Public and consumer AI use is not accepted here simply because it is convenient. Candidates design private routes, minimise context, isolate clients, enforce retention, test for leakage and maintain an audit trail that reconstructs what happened after the fact.

Every exam report carries an AI use manifest: which models were approved, which deployment classes were used, which agents and tools ran, which data classes were exposed to them, what the policy engine decided, and where a human made the call.

A client should be able to ask “what did your AI see?” and get a precise answer.