The AI sector is witnessing a broad debate regarding the mechanisms for governing and evaluating advanced models before deployment. However, these major discussions often overlook the actual code that determines whether an AI agent is permitted to perform sensitive actions, such as sending emails, modifying encryption keys, merging software branches, or transferring funds. These decisions are not made by major laboratories or regulatory texts, but by simple programmatic functions that return a true or false value.
Stress tests conducted on an open-source protocol for verifying agent actions, called "PIC," showed that problems do not necessarily stem from encryption failure, but from the protocol accepting multiple, superficially valid formats that are subject to different interpretations. For example, a schema might accept hash codes in uppercase or lowercase, while the interpreter handles them in ways that lead to divergent results between systems without violating the declared standard specifications.
The Limits of JSON Schemas in Data Validation
JSON schemas play an essential but limited role in validating data structure; they ensure the presence of required fields, the correctness of their value types, and their compliance with general rules. However, the schema is unable to enforce complex relational rules, such as ensuring that a specific reference to tools points to a single element within an array of sources without duplication or ambiguity.
Differences in the implementation of search operations or identifier matching between different programming languages lead to what is known as parser differential, an old type of security vulnerability that previously appeared in protocols like HTTP and JWT, where two components read the same input in two different ways. In modern agent protocols, these nuances lead to actions being accepted in one service while being rejected by another that uses the same policy and specifications.
The Impact of Normalization on Protocol Security
Developers typically tend to normalize inputs to avoid rejecting recoverable data, such as removing extra spaces, converting characters to lowercase, or fixing Base64 padding. However, these practices pose a real danger at the authentication boundary. For example, if the interpreter normalizes a tool name or removes spaces before matching it against an allowlist, the system might execute an action not approved by the signing party or manipulate execution permissions without the developers' knowledge.
Furthermore, relying on fields sent by the agent itself to attest to the reliability of its source opens the door to the confused deputy problem in a digital format. Trust must be derived exclusively within the boundaries of enforcement and verification, by checking digital signatures and matching them against cryptographic keys directly trusted by the operator, regardless of the claims contained in the request payload.
The Three-Layer Architecture and Execution Matching Vectors
To avoid these vulnerabilities, an architecture that clearly separates three consecutive layers is required:
- Schema Validation: To reject malformed structures and representations that do not conform to the network.
- Semantic Validation: To resolve references, verify associations, and derive actual trust.
- Policy Evaluation: To make the final decision on whether to allow or block the execution of the action.
Documentation notes are not enough; clear execution matching test tools are required, including precise inputs, expected results, and stable error codes to handle ambiguous cases. These vectors ensure consistent behavior across all implementations and prevent security from relying on divergent default configurations in different software bridges.