Security Measures

AgentChamp - Technical and Organisational Measures

Effective 25 August 2026

This is the full statement of the security measures referenced by Annex B of our Data Processing Agreement. It is written to be assessed, not admired: where a control is not yet in place, it says so.

AgentChamp Ltd - company number 17176256, ICO registration ZC230270. Security contact: security@agentchamp.co.uk.

1. Where data lives

Everything is hosted on Google Cloud in europe-west2 (London): the PostgreSQL database, the Redis cache, the application servers, the task queue, file storage and logs. Narration synthesis uses Microsoft Azure Speech in UK South.

The production database has no public IP address - it is reachable only from inside the private network, and the infrastructure code has a module-level validation that prevents that being flipped by accident.

2. Encryption

• In transit: TLS on every connection, external and internal.
• At rest: encrypted by the hosting provider across database, cache and object storage.
• Passwords: stored as bcrypt one-way hashes. They cannot be recovered, by us or anyone else.
• Pupil login codes and PINs: additionally held under AES-256-GCM encryption, because they must be *re-showable* - a seven-year-old who forgets a login must not be locked out of reading. Every reveal is written to an audit log naming the member of staff who did it, whole-class credential sheets can only be produced by staff assigned to that class, and these fields are stripped from every data export.

3. Access control

• Role-based access, scoped to school and to class. A teacher sees their classes; a school administrator sees their school; nobody sees another school.
• A pupil can access only their own data. There is no route by which one child sees another child's reading, name or progress.
• Parents see only children linked to them, and only through a school-issued single-use link code.
• Server-side session revocation: a session can be killed centrally, not merely expired.

4. Authentication

• Short-lived access tokens held in memory only - never written to disk.
• Refresh tokens in HttpOnly, SameSite=Lax, Secure, path-scoped cookies that no script can read. This was changed deliberately from browser local storage, which cross-site scripting can reach.
• Rate limiting and lockout on every authentication endpoint and on link-code entry, to defeat guessing.
• Email verification required before an adult account becomes usable; verification and password-reset links are single-use and expire.
• Unverified registrations are deleted automatically after 24 hours.

5. Outbound network control

The backend maintains an explicit allow-list of every external host it may contact, enforced by intercepting the HTTP layer itself rather than by convention. An attempt to reach an unlisted host raises a security event.

Production is configured fail-closed: an unlisted host is blocked, not merely logged, so a compromised dependency attempting to exfiltrate data fails rather than succeeding quietly. Pre-production environments run it in warn mode instead, so a new integration surfaces as a log line during development rather than an outage.

Being precise, because the difference matters: fail-closed is a deployment setting (EGRESS_ALLOWLIST_STRICT), not the library default, and it is a blocking item on our pre-production checklist. The allow-list itself is enforced in every environment; what the setting changes is whether a violation is refused or recorded.

The allow-list is short, and shrinking: removing the dictionary provider in August 2026 took two hosts off it.

6. Data integrity and audit

• The consent audit record is append-only, enforced by a database trigger, not by application convention. A compromised application role cannot rewrite the evidence that consent was obtained or that an erasure was carried out. Corrections are made by appending a compensating event.
• Credential reveals, data exports, consent events and erasures are all recorded with actor, subject, timestamp and document version.
• Personal identifiers are masked or hashed in routine application logs. The consent audit record keeps exact values because it is evidence - and those identifying elements are erased after six years.

7. Deletion

• Retention and erasure run as automated daily jobs, not as a promise somebody has to remember to keep.
• Erasure is a genuine cascading delete across every table holding the account's data, executed in a transaction, with the evidence of erasure written before the delete so the two share a fate.
• Two stages: immediate deactivation, then irreversible purge after 90 days. The grace window exists so an accidental deletion can be undone, and a school may ask in writing for it to be waived.
• Payment-provider payloads are reduced to a bare summary after 180 days, and redacted immediately when the associated account is purged.

8. Application security

• Content Security Policy on both the application and the marketing site, with every permitted source justified by a real call site.
• Permissions-Policy denies camera, microphone and geolocation outright. The platform cannot ask for them.
• Parameterised database queries throughout.
• Webhooks verified against signing secrets.
• No third-party resource loads on any page a child can reach - no fonts, no images, no scripts. The only third-party load anywhere is Stripe's payment form on adult checkout pages.

9. Build and deployment

• Separated development, integration and production environments, with separate credentials.
• Automated secret scanning in the continuous-integration pipeline; a build carrying a credential fails.
• Dependency vulnerability scanning on every pull request, blocking on critical findings.
• Lockfile integrity enforced.
• Changes are reviewed before merge; branch protection prevents direct pushes to the main branch.
• Deployments are versioned and roll back to the previous revision in one command; the old version keeps serving until the new one reports healthy.

10. Backups

Encrypted automated backups with 30-day retention in production (7 days in pre-production), including transaction-log retention for point-in-time recovery. A deleted account disappears from backups as they roll off.

11. People

• Access to production data is limited to those who need it to operate the service.
• Everyone with access is bound by confidentiality obligations.
• AgentChamp is a small company; access is correspondingly small. We would rather state that plainly than describe a segregation-of-duties structure we do not have.

12. Incident response

• Whoever discovers an incident affecting a school's data informs that school within 48 hours, for every personal data breach - not only those we judge significant. Deciding severity is the controller's job, and a school cannot make that decision about a breach nobody told it about.
• Notifications carry the Article 33(3) information so far as it is known, with further detail following in phases.
• We support the school's own reporting to the ICO and to data subjects.

13. Responsible disclosure

Found a vulnerability? security@agentchamp.co.uk.

Report it privately, give us a reasonable chance to fix it before disclosing, do not access or modify anyone else's data, and do not degrade the service while testing. Within those limits we will not pursue legal action against anyone reporting a genuine vulnerability in good faith. We will acknowledge your report and tell you what we did about it.

14. What we do not have

Stated because a security document that only lists strengths is not an assessment.

• No independent security certification. We do not currently hold Cyber Essentials, Cyber Essentials Plus, or ISO 27001. Our controls are published above so they can be judged on their merits, and this is under active consideration.
• No third-party penetration test. We run internal security audits with documented findings and tracked remediation, but have not yet commissioned an external test.
• No 24/7 on-call rota. We are a small team and respond during working hours, faster for anything involving children's data.
• No formal SOC or intrusion-detection service. We rely on hosting-provider logging, alerting on authentication anomalies, and the outbound allow-list.

If any of these is a blocker for your school's assessment, tell us - knowing which ones matter to buyers is how they get prioritised.

15. Review

Reviewed whenever the architecture changes materially, and in any event annually. Last reviewed 25 August 2026.