Separating Disclosure from Authorization: Field-Tier Minimization for Agent Action Mediation

In the modern digital world, autonomous software agents act on behalf of people and companies, sending emails, moving money, and accessing sensitive records. To keep these agents safe and honest, organizations use two distinct systems that often work at cross-purposes. The first is a gatekeeper, a policy engine that must look at the details of an action to decide if it is allowed. If an agent wants to email a recipient, the gatekeeper needs to see the address to know if that person is inside or outside the company. The second system is a permanent record, an unchangeable log that writes down every decision made, creating a trail that auditors can inspect years later to prove what happened. The problem arises because both systems traditionally demand the same thing: the raw, unfiltered data. The gatekeeper needs the full details to make a fair decision, and the log needs the full details to be a trustworthy witness. But this creates a dangerous bottleneck where the most private information—names, addresses, and medical details—gets trapped in a permanent, unerasable ledger, violating the very privacy rules the organization is trying to follow.

A team of researchers at Aurite AI has found a way to untangle these two needs without sacrificing security or privacy. They discovered that the gatekeeper and the record-keeper do not actually need to see the same things. The gatekeeper only needs to know the shape of the data to make a rule-based decision, while the record-keeper only needs to know that a specific decision was made about a specific set of data. By separating these requirements, the researchers created a system where the private details never leave the user's computer, yet the organization can still enforce rules and keep an unbreakable audit trail.

The core of their solution is a method called field-tier minimization. Instead of treating an entire action, like "sending an email," as a single block of sensitive data, the system breaks the action down into its individual parts, or fields. It then sorts each field into one of three categories. The first category contains information that is necessary for the rules but does not identify a person, such as the size of an attachment or the number of files. This data is allowed to pass through in its original form. The second category holds information that is needed for the rules but is also personally identifying, such as an email address. For these fields, the system does not pass the full address. Instead, it passes a simplified, non-identifying version, such as just the domain name after the "@" symbol. This allows the gatekeeper to check if the email is going to an external company without revealing the specific person's name. The third category contains information that is never needed for the rules, such as the subject line of an email or the notes on a payment. This data is kept entirely within the user's computer and never crosses the boundary to the outside world.

The brilliance of this design lies in how it handles the permanent record. In many previous attempts to protect privacy, systems would try to hide or delete sensitive data before writing it to the log. However, this creates a new problem: if the log is altered, an auditor cannot tell what was removed or if the record is trustworthy. The researchers solved this by having the computer compute a unique digital fingerprint of the original, unaltered data before any hiding or simplification happens. This fingerprint is then written to the permanent log. Later, when the simplified data is sent to the gatekeeper, the system can still prove that the simplified version came from the original data because the fingerprint matches. This means the organization can change its rules about what data to hide at any time, even years after the fact, without breaking the integrity of the old records. The log remains a solid, unchangeable witness to the original event, while the flow of information to the gatekeeper becomes flexible and privacy-friendly.

To ensure this system works correctly, the researchers had to solve a tricky question about trust: who gets to say what happened? Since the sensitive data never leaves the user's computer, the user's computer is the only one that can compute the fingerprint of the original data. The researchers decided that the user's computer should be the one to create this fingerprint and report it to the log. They reasoned that if a user tried to lie about the fingerprint, they would be forging evidence against themselves, which is a strong deterrent. However, the user's computer cannot be trusted to say which rules were used to simplify the data, because it could simply claim it used a different set of rules to hide more information. To prevent this, the system requires the user's computer to send a fingerprint of the rules it used, and the central server checks this against the official rules. If the two fingerprints do not match, the system knows something is wrong and rejects the action. This creates a balance where the user is trusted to report the data they hold, but the server is trusted to verify the rules applied.

The researchers tested this system with real-world scenarios, including sending emails and accessing medical records. They found that their method successfully prevented sensitive identifiers from ever leaving the user's environment while still allowing the policy engine to make accurate decisions. In one specific test, they examined a resource path that included a patient's record number. Their initial attempt to simplify this path failed because it left the number visible in the text. They fixed this by changing the rule to remove the entire final part of the path rather than trying to clean the text, ensuring that no identifying information slipped through. Their analysis showed that for the actions they studied, nearly half of the data fields never crossed the boundary in their raw form, and the remaining fields were reduced to non-identifying summaries.

The team acknowledges that their system is not a perfect shield against every possible threat. If the user's computer itself is hacked, the attacker could still send whatever data they want. The system is designed to protect the data as it moves from the user to the organization, not to protect the user's computer from being compromised. Furthermore, the researchers note that their current rules are static; they cannot easily change based on complex situations, such as deciding that a field is sensitive only if the recipient is in a different country. Despite these limits, the approach offers a practical and structural way to handle the tension between privacy and accountability. It proves that you do not need to choose between a strict, unchangeable audit trail and a flexible, privacy-respecting policy. By computing the commitment to the data before simplifying it, and by carefully assigning who gets to verify what, the system allows organizations to govern their agents effectively without exposing their customers' private lives to the permanent record.