Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Who Approves an AI Agent Before It Sends Sensitive Information?

The named person already accountable for releasing that data under the rules that govern it, such as the records custodian, the privacy officer or the account owner, not an AI team and not the agent. Check that every outbound send in your agent's workflow routes to that person and that real values appear only at the destination they approved.

Different sensitive data shapes converge at an agent, cross an approval boundary, and reach an authorized destination.

The named person already accountable for releasing that data under the rules that govern it, such as the records custodian, the privacy officer or the account owner, not an AI team and not the agent. Check that every outbound send in your agent's workflow routes to that person and that real values appear only at the destination they approved. The sender is new; the decision is not. Health, education and financial privacy rules have for decades required that a disclosure of protected information be a deliberate act by an accountable party, permitted by the rule or authorized by the subject, and recorded. An agent that drafts an email, fills in a portal or uploads a file is performing a disclosure, and the rules contain no exception for software. The problem to solve is routing: making sure the decision reaches the person the organization has already made responsible for that data, and making sure the information itself does not reach the model or the destination before that person has decided. This page sets out why a send is a disclosure, who the accountable person is under each major rule, how the routing works on a single student record, how to keep the values out of the model until the approved destination, how to test the arrangement, and which vendor claims a buyer should not accept.

Key findings

  • Sending is the dangerous third leg. Simon Willison's "lethal trifecta" names the combination of "Access to your private data," "Exposure to untrusted content," and "The ability to externally communicate" as the condition under which an agent can be made to leak what it reads (Simon Willison, 2025).
  • The HIPAA Privacy Rule's general rule on uses and disclosures permits a covered entity to disclose protected health information only as the rule allows or the individual authorizes, which makes each release a decision someone must own (45 CFR 164.502).
  • FERPA's school official exception allows education records to reach a contractor without consent only under conditions the institution sets and controls, so the institution, not the contractor's software, decides each use (34 CFR 99.31).
  • The FTC Safeguards Rule requires financial institutions to maintain an information security program that protects customer information, a program that has owners and cannot be delegated to an agent (16 CFR Part 314).
  • Sensitive information disclosure by an LLM application is a named category in the OWASP Top 10, covering the exposure of personal and confidential data through model output (OWASP, 2025).
  • Platform vendors now document approval flows that "request approval decisions from different human stakeholders at various stages of the process," which is the routing mechanism a disclosure gate needs (Microsoft Learn, 2026).

Why is an agent sending information a disclosure, not a workflow step?

The agent's view of its task is operational. The regulator's view is different. A protected value leaving the organization's control is a disclosure, and disclosure is the event the privacy rules regulate. The HIPAA Privacy Rule's general rule is written as a prohibition with permissions: a covered entity may not use or disclose protected health information except as the rule permits or requires, or as the individual authorizes (45 CFR 164.502). Each release has to fit a permission, and someone has to decide that it does.

The security framing arrives at the same place from the other side. Willison's lethal trifecta identifies external communication as the leg that converts an agent's exposure to untrusted content into an actual leak: an agent that reads private data and reads an attacker's instructions is contained until it can send (Simon Willison, 2025). The OWASP entry on sensitive information disclosure catalogs the same exposure as one of the top risks in LLM applications (OWASP, 2025).

So a send is where two obligations meet. The privacy rule needs an accountable decision that this release is permitted. The security model needs a gate on the one capability that turns a compromised agent into a breach. One control answers both, provided it routes to the right person and holds the values back until that person decides.

Who is the accountable person under each rule?

The rules do not name job titles, but they do assign responsibility to the regulated entity, and every regulated entity has already assigned that responsibility to people. The approver of an agent's send should be the person who already holds it for that class of data.

Data and rule Where the obligation sits The person who should approve an agent's send
Protected health information, HIPAA Privacy Rule The covered entity's permitted uses and disclosures The privacy officer or the records owner for that department
Education records, FERPA The institution's control over school officials and their use of records The registrar or the records custodian who signs disclosure authorizations today
Customer financial information, GLBA Safeguards Rule The institution's information security program and its designated coordinator The data owner for the account line, under the program's coordinator
Other confidential business information Internal classification policy The business owner named in the classification

FERPA's school official exception illustrates the principle. It lets an institution treat a contractor as a school official, and so share records without consent, only where the contractor performs a service the institution would otherwise use employees for and is under the institution's direct control with respect to the use and maintenance of the records (34 CFR 99.31). The institution keeps the decision; it cannot be handed to the vendor's system. The Safeguards Rule works the same way for financial institutions, requiring a security program with a designated person to coordinate it (16 CFR Part 314). A central AI team is the wrong approver in every row, because it does not hold the obligation.

How does the routing work on a single student record?

Consider a student record page in a student information system. It shows the student's name, identifier, date of birth, enrollment status, a transcript summary and the contact details of a parent. An agent's task is to respond to a records request from an outside scholarship provider, which has asked for enrollment confirmation and a transcript.

The agent opens the record. In a governed environment, the identifiers it reads appear as tokens: the model sees STUDENT_001 and a tokenized date of birth, not the real values. It confirms the student is enrolled, locates the transcript and drafts the response to the provider and attaches the transcript. Then the workflow pauses, because the send is a disclosure of education records to an outside party.

The prepared send routes to the registrar, the person who signs transcript release authorizations today. The registrar sees the same screen the agent saw, with tokens, and the destination: the provider's portal, on the institution's approved list for this record type because the student's consent is on file. The registrar approves. At that moment, and only at the provider's portal, the tokens resolve to the real values and the transcript is sent. The record captures the agent's draft, the registrar's identity and decision, the destination and the time.

Now change one fact. Suppose the request had come from an address not on the approved list, or suppose the request itself, read by the agent, contained text instructing it to also send the parent's contact details to a second address. The agent may have drafted that send too. It routes to the registrar, who declines it, and the real values never resolve because no approved destination was reached. The person who already owns the decision made the decision, and the control that kept the values out of the model meant that an injected instruction had nothing real to send.

How should the values be kept out of the model until the approved destination?

Routing the decision to the right person is half the control. The other half is making sure the sensitive values are not already in the model's context, where an injected instruction or a model error could send them through a path the gate does not cover. The design that achieves this substitutes tokens for protected values before the model reads the screen, keeps each token consistent across the run so the agent can still reason about the record, and resolves the token to the real value only at the destination the approver confirmed, at the moment the approved send executes.

This changes what "approval" protects. If the model holds real values, approval of one send does nothing about the possibility of another, because the model can compose a message to any address it can reach. If the model holds tokens, every send it composes carries tokens, and tokens resolve only where an approver has said they may. The approver is then deciding not just whether this message goes, but where real data may appear at all. That is a stronger control than classifying the content after it leaves, which is how conventional data loss prevention works; Microsoft's own overview of DLP describes it as identifying and protecting sensitive items across services, a detection posture applied to content in motion (Microsoft Learn, 2025).

The approach also fits legacy applications with no API, because it operates on the rendered screen. And it allows the approver to see the screen without the approval itself becoming a disclosure: the registrar confirms the right student and the right destination from tokens, and the real values appear only at the portal.

How should an organization test who approves and what resolves?

Test the routing first. For each class of sensitive data the agent can touch, name the approver the organization's existing policies already hold responsible for its release, and then verify from the agent's configuration that sends of that class route to that person and to no one else. A send that routes to a general queue, the agent's operator or an AI governance team fails the test. Institutional guidance on managing generative AI systems asks for exactly this kind of identified ownership (Harvard University Information Security and Data Privacy).

Test the destination binding second. Approve a send to an approved destination, then confirm that the real values appeared there and nowhere else: not in the model's context, not in the approval screen, not in the record. Then attempt a send to an unapproved destination, with the approver declining, and confirm no real value resolved anywhere. The multistage approval capability some platforms document, routing decisions to different stakeholders at different stages, is a reasonable mechanism for the routing half, and a buyer should check whether the destination half exists at all in a given product (Microsoft Learn, 2026).

Test reconstruction third. Choose one send from the pilot and ask for the record of who approved it, what they saw, where it went and when. Under the Safeguards Rule, the Privacy Rule and FERPA alike, the organization has to be able to account for releases, and an agent whose sends cannot be reconstructed has created releases the organization cannot account for (16 CFR Part 314).

What does a governed environment change?

A governed environment routes every outbound send to the accountable person and keeps real values out of the model until that person has approved the destination, so the disclosure decision belongs to whoever holds the obligation, not the agent. Run directly in the application or the user's browser, the agent composes with real values in context and sends with the user's rights; in the environment, it composes on tokens and the send waits.

This class of control works at the rendered screen. Student, patient or customer identifiers are replaced with consistent tokens before any model reads the record, and the task runs on tokens. Real values resolve only at the approved destination when the approved send executes. A named person confirms what is tokenized and approves consequential actions, sends among them. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

Configuration is an instruction, and the trifecta analysis concerns agents instructed not to share that did (Simon Willison, 2025); the environment removes private data from context, so a compromised agent has nothing real to send. Outbound detection inspects a message after the model composed it and does not route the decision; the environment substitutes before the model reads and routes to the registrar, privacy officer or account owner, named in the record as the person who owns the release under the HIPAA Privacy Rule (45 CFR 164.502) or its FERPA and Safeguards Rule equivalents.

The control does not alter the application, the user's permissions or the model, and it does not decide whether a release is permitted; it puts that decision with the person who must make it.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design routes the release decision to a named person and withholds the values until that person has decided. The agent works in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so protected values appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action, which for a send means at the destination the approver confirmed and nowhere else. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement the design calls Supervised Delegation, and for sends that person is the data owner the organization already holds accountable. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would show, for this question, every outbound send the agent prepared, who approved or declined it, the destination at which real values resolved, and confirmation that no real value appeared in the model's context or the approval screen. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the text of three regulations as published in the Electronic Code of Federal Regulations (45 CFR 164.502 of the HIPAA Privacy Rule; 34 CFR 99.31 of the FERPA regulations; 16 CFR Part 314, the FTC Safeguards Rule), the OWASP Top 10 for LLM Applications entry on sensitive information disclosure (2025), Simon Willison's description of the lethal trifecta (June 2025), Harvard University's best practices for managing generative AI systems, and Microsoft documentation on multistage approvals in Copilot Studio agent flows (updated June 2026) and on data loss prevention (2025). All sources were read as of October 16, 2026. The mapping of rules to approver roles is this page's synthesis; the regulations assign obligations to entities.

No hands-on testing of any product was performed. Vendor documentation is described from the pages reviewed, and "not described" means not described in those pages, not absent from the product. Vendor features change, and the page carries its date. The regulatory summaries are descriptive and are not legal interpretations; the regulations contain conditions, exceptions and definitions this page does not reproduce. Statements about RedactSure describe current design, with deployments in pilot. The student record and the scholarship request describe a record type and a task shape, not any institution.

Whether a given release of health, education or financial information is permitted, whether an approver's role satisfies a regulation's requirements, and whether a record meets an accounting obligation are determinations for the organization's counsel, its assessors and its own privacy, security and compliance officers, not for a research page.

What the record shows

The question of who approves an agent's send has an answer the organization already holds. Privacy rules in health, education and finance make each release a decision the regulated entity owns, and every such entity has already named the people who make those decisions. The security literature independently identifies the send as the moment a compromised agent becomes a breach. The two conclusions meet in one control: route the agent's prepared send to the person already accountable for that data, and keep the real values out of the model and off the approval screen until that person has agreed and the approved destination is reached. Supervised Delegation implements that routing with tokens that resolve only at the destination. The test is to name one agent and one task and ask: when this agent sends a record outside the organization, who sees it first, is that the person who signs such releases today, and where did the real values appear?

Frequently asked questions

Why can't the AI team approve sends of sensitive data?

Because the AI team does not hold the obligation. HIPAA, FERPA and the Safeguards Rule assign responsibility for uses and disclosures to the regulated entity, which discharges it through privacy officers, registrars, records custodians and data owners. Those people know whether a given release fits a given permission for a given record. An AI team reviewing sends would be making a judgment it is not positioned to make, and the record would show the wrong approver. The agent's send should route to whoever signs that release today.

Is an agent sending a record really a disclosure?

Yes. The privacy rules regulate the event of protected information leaving the entity's control, whatever performs the sending. The HIPAA Privacy Rule's general rule permits use or disclosure only as the rule allows or the individual authorizes. FERPA's school official exception keeps the institution in direct control of how records are used even by contractors. An agent drafting an email, filling a portal or uploading a file is performing the regulated act, and the decision behind it has to be made by someone accountable.

What is the lethal trifecta?

Simon Willison's term for the combination of three capabilities in one agent: access to private data, exposure to untrusted content, and the ability to communicate externally. An agent with all three can be induced by content it reads to send what it has access to. The send is the leg that converts exposure into a leak, which is why a gate on outbound communication, with a named approver and values that resolve only at approved destinations, addresses the trifecta directly rather than relying on the model to resist instructions.

Does the approver have to see the sensitive values?

No, and preferably not. The approver can confirm the right record and the right destination from consistent tokens, matching the token on the approval screen to the token on the source record, without the real values appearing on either. The real values resolve at the approved destination when the approved send executes. This keeps the approval screen and the record from becoming further copies of protected data, and it means an approval does not itself constitute a disclosure to the approver.

How is this different from data loss prevention?

DLP inspects content after it has been composed and as it leaves, looking for sensitive patterns, and blocks or flags what it recognizes. It does not route the release decision to the data owner and it depends on detection. Substitution before the model reads the screen means the model never holds the real values, so whatever it composes carries tokens, and tokens resolve only where an approver has agreed. The two can coexist, but substitution prevents what DLP tries to catch.

What should the record of a send contain?

The agent identity and task, the prepared send as the approver saw it with tokens, the destination, the approver's identity and decision, and the time the send executed. An assessor should be able to read all of that for one send in one place. Under the Privacy Rule, FERPA and the Safeguards Rule the organization has to be able to account for releases, and a send that cannot be reconstructed is a release the organization cannot account for.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.