Common questions from security leads

A containment layer for a vendor holding many districts’ student data in one platform. It governs how every authenticated actor, human or machine, reaches that data, and it bounds the blast radius of access already granted.

The key that decrypts district records lives outside your environment, in a custody tier the district elects, under a policy that denies decryption to AgenticED and to you. A full compromise of your estate yields ciphertext.

Yes. A person and an agent are held to the same five conditions. The only difference is how the first is proven: a person with a fresh signed assertion from your identity provider, an agent with a registered, non-revoked credential.

They are different products, and neither depends on the other. Certification judges whether a vendor’s software should be trusted with student data. Guardian governs reach and makes no judgment of that kind.

You can run Guardian without being certified, and being certified does not put you under Guardian.

The credential alone is not enough. Every request is decided at the time of the request against five conditions: a fresh assertion from your identity provider, scope to the district’s tenant, a live verified MFA session, an approved role and operation, and a record ceiling inside the grant.

A stolen credential reaches at most what its owner was approved to reach, and bulk export or restore needs a live work assignment as well. A request outside the approval is denied, recorded against the district’s tenant, and raised to the district.

At every custody tier the key policy denies decryption and data key generation to AgenticED principals, and the runtime that uses the key cannot rewrite its own policy. An intruder in our estate does not acquire the ability to open district records.

At Tier B and Tier C the key sits in the district’s own AWS account or its own HSM.

Every path fails closed. Where Guardian is wrong, it is wrong in the direction of less access.

No. Guardian does not read content, inspect traffic, or judge model output. It decides whether a request may proceed and records the decision.

No. Your SOC 2 Type II runs as it does today, and your penetration testing and privacy certifications are unchanged. A SOC 2 report attests that controls exist and are followed. Guardian is a control: it changes what a breach of your estate can reach.

Breach response cost is driven by not knowing what was reached, so counsel assumes the worst and everyone is notified. A per-district record of every access decision makes the scope provable.

What leaves a compromised estate is ciphertext under a key you cannot open, and most state breach-notification statutes carry an encryption safe harbor. Whether a safe harbor applies to a given incident is a question for your counsel.

The obligations you already carry in every DPA become enforced in the database rather than promised on paper.

Four connections, and it comes together in a week: the MCP gateway, your current key, your workflow tool, and your CRM.

Nothing. No schema change, no application rewrite, no data migration, no roster authored, no integration written. Guardian reads the answers out of the systems you already run and shows you what it found. Your engineers keep their access.

We do not quote a figure yet. Latency will be measured by the independent security assessment, and we will publish that measurement.

Elect a custody tier, approve the declaration, and review the record. There is no integration work, no license, and no system for the district to administer.

The vendor buys it and operates it. Guardian costs the district nothing.

Talk to Alvin Crawford at alvin@agenticed.com. The first conversation covers your estate, your workflow tools and your CRM, which is everything Guardian needs to read.