Security Overview

AgenticED, Inc.
Effective Date: October 13, 2026

This page describes the controls that protect district data in the AgenticED platform. Every control listed here was checked against the platform's own database schema, infrastructure code, and application code.

This page also summarizes our written information security program, which the amended COPPA Rule requires of an operator that handles children's data. AgenticED's Chief Compliance Officer is responsible for the program. We assess risk and review the program at least once a year, and we require written security commitments from each service provider that processes student data.

District security teams that need more detail than this page provides can request our full security documentation, under a non-disclosure agreement where the detail calls for one.

Architecture

The platform runs on Amazon Web Services in the United States. Application containers and the database run in private network subnets. The database is not reachable from the internet. It has no public address, and the only path into the environment is through a load balancer that terminates encrypted connections.

There is no bastion host and no administrative network path into the production environment.

Encryption

In transit. All traffic between your browser and the platform is encrypted with TLS. Our load balancer requires TLS 1.2 or higher and supports TLS 1.3. Certificates are issued and rotated through AWS Certificate Manager, and plain HTTP requests are redirected to HTTPS.

At rest. The database is encrypted with a customer-managed key. Every stored secret is encrypted with a customer-managed key. Documents uploaded to the family document vault are encrypted as they are written, and the encryption applied to each document is recorded alongside it, together with a checksum.

Per-district keys. The platform supports per-district key management, including the option for a district to hold its own key. The design keeps the platform from decrypting a district's data on its own, and it includes a process for moving existing data under a district's key. This option is available to districts on request.

Access Control

Authorization Is Enforced in the Database

Row-level security is forced on 385 of the platform's 579 tables, with 1,434 policies.

The difference between enabled and forced row-level security matters. Enabled row-level security exempts the table's owner. Forced row-level security does not, so the policy binds even a connection that owns the table.

Forced policies cover the tables that hold student records, family records, household financial ranges, benefits claims, uploaded documents, special education plans, discipline referrals, staff records, agent sessions, and the audit log itself. The practical result is that a defect in our application code cannot hand one district's student records to another district, because the restriction is enforced below the application. The tables without row-level security hold public reference and catalog data, such as school directories, academic standards, benefit program definitions, and supported languages, which contain nothing specific to a district.

Agent conversation transcripts are isolated by session, through the application, instead of by a database policy.

The Most Sensitive Paths Are Closed in the Database

For the most sensitive reads, the application's direct access to the underlying tables is revoked, and access runs only through defined database procedures. Our own application code cannot read around them.

Employee workforce signals are the clearest example. Three rules are enforced in the database:

• An administrator, superintendent, or HR administrator is routed to an aggregate and can never reach an individual record. The individual view is reserved to the employee.
• An aggregate is suppressed, returned with no number and a suppressed status, unless the group meets a minimum size. The minimums are seven for general signals, fifteen for sensitive signals, and ten for grievance-related signals, and a database constraint keeps a district from setting a floor below those values.
• A request whose stated purpose is employee evaluation, or that comes from an evaluator role, is refused with an error.

We describe this in detail because where a rule is enforced decides whether it holds. A policy that says administrators should not see individual employees is a promise. A database that refuses to return one is a control.

Authentication

Student sign-in is deliberately simpler. Students can use sign-in links and QR codes as well as standard methods, because a sign-in a nine-year-old cannot complete is one that gets shared with a teacher. These methods are less strong than a password with a second factor, and each district chooses which methods its students may use.

Consent as Part of Authorization

Consent in the platform is an input to every authorization decision. It is recorded for each purpose and scope, can be revoked for each purpose, and has its own access log and audit trail. A district decides which parent relationship and custody combinations may grant consent for a student. A combination the district has not decided is denied.

Agent Authorization

Agents that reach district data are authorized by a certification grant: approved read domains, approved write domains, a maximum sensitivity tier, and explicit flags for special education and health data. The gateway checks an agent's declared data needs against its grant. This rule governs our own agents as well as third-party agents.

Audit Logging

Every change to platform data is written to an append-only audit log that records the actor, the actor's role and type, the action, the resource type and identifier, the originating address, the user agent, the request path and method, the response status and timing, the result, any denial reason, the data category and classification, the consent basis, and the district.

Access to the most sensitive records has dedicated logs of its own: document access, consent access, vendor and agent reads, pseudonymization key use, data sent to community partners, token use, sign-in events, and tool calls.

The audit log has three properties that make it more than a table of events:

It is tamper-evident. Each entry carries the hash of the previous entry, its own hash, and a sequence number. An entry cannot be altered or deleted without breaking the chain, and the chain is verified independently.

It is written through a single path. One service writes audit entries. There is no second way to produce one.

It cannot be anonymous. A database constraint rejects any entry without an identified actor.

The log also stores salted hashes of the actor, resource, and originating address alongside the plain values, so analysis can be performed without exposing identifiers.

Secrets

All credentials are held in AWS Secrets Manager and resolved at runtime. Signing keys are generated by our infrastructure code and never exist in a code repository. Secrets are encrypted with customer-managed keys and have a recovery window.

Access follows least privilege. Our separately deployed products do not inherit the platform's administrative credentials, payment keys, or monitoring keys.

Vulnerability Management

Container images are scanned for known operating system and library vulnerabilities on every build.

A recurring automated check tests the live data-access posture of our separately deployed products against required rules: tenant isolation, identifiers that reveal nothing, deny-by-default access, and the separation that keeps the platform from decrypting a district's data on its own.

Monitoring

Application metrics and logs are collected in Amazon CloudWatch. Application performance data in production is collected in Datadog, which is listed as a service provider in our Privacy Policy.

Resilience

Production databases are backed up automatically every day, and backups are kept for seven days. Deletion protection is enabled on production databases and load balancers. Object versioning is enabled on infrastructure and website storage.

Data Retention and Deletion

Our retention schedule is published in our Privacy Policy and is a commitment to districts.

Directed erasure removes records across more than sixty tables in a single operation that either completes entirely or changes nothing. It does not anonymize records, set a deleted flag, or hide records in place of deleting them. If a table cannot be cleared, the operation reports it instead of skipping it.

Each erasure produces a receipt: what was deleted, the record counts, and each kind of record deliberately kept, with the reason for each. The records kept are audit and consent evidence.

Incident Response

If we confirm a security incident affecting district data, we will:

• Notify the district within seventy-two hours of confirming it
• Tell the district what we know, what data was involved, and what we are doing about it
• Support the district in meeting its own obligations to notify families and authorities
• Preserve the evidence

The tamper-evident audit log supports this work, because it helps establish what was and was not changed or disclosed.

Reporting a Vulnerability

If you believe you have found a security vulnerability in an AgenticED product, write to security@agenticed.com with a description and the steps to reproduce it.

• We will acknowledge your report within five business days and keep you informed as we investigate.
• Please do not access, change, or keep data that belongs to anyone else, do not degrade the service, and give us a reasonable time to fix the issue before you disclose it publicly.
• We will not pursue legal action against anyone who reports a vulnerability in good faith and follows these guidelines.

Certifications

AgenticED does not currently hold a third-party security certification. We align our security program to the NIST Cybersecurity Framework, which is the framework named in Exhibit F of our Data Processing Agreement and the framework our vendor certification program applies to third-party agents.

Contact

AgenticED, Inc.
Attn: Chief Compliance Officer
240 West 136th Street
New York, NY 10030

Security: security@agenticed.com
Privacy: privacy@agenticed.com