Eight sections — from the unguarded boundary surface to the deployable specification deliverable.
Every AI system has a boundary. Inputs cross it in one direction — user prompts, API calls, sensor data, tool results, configuration changes. Outputs cross it in the other — responses, actions, state changes, artifacts, signals to downstream systems. The boundary is where the system meets the world. And in most deployed AI systems, it is the least governed surface in the entire architecture:
The typical answer: inputs are parsed and outputs are filtered. But parsing is not validation. Filtering is not gating. And neither constitutes a governed boundary with defined behavior under failure.
The boundary problem has a specific structure that distinguishes it from general input validation. An AI system’s boundary is not just a data interface — it is a trust interface. Everything outside the boundary is untrusted by definition. Everything that crosses the boundary becomes, at least partially, trusted by the system that receives it. The transition from untrusted to trusted is the most consequential moment in the system’s operation, and it is typically ungoverned.
This matters because the most effective attacks on AI systems exploit the boundary, not the model. Prompt injection works because the boundary does not distinguish between instructions and data. Tool-result manipulation works because the boundary treats tool outputs as trusted input. Configuration injection works because the boundary does not validate whether a configuration change is authorized at the semantic level, not just the authentication level.
The output boundary is equally ungoverned. AI systems produce outputs that cross into downstream systems, trigger actions, modify external state, and influence human decisions. These outputs leave the system through interfaces that are designed for throughput, not for governance. No mechanism gates whether an output should be released given the system’s current risk state, whether the output is consistent with the system’s governance constraints, or whether the output boundary should be locked during a critical event.
This is the boundary defense gap. It exists at every interface where the system exchanges information with the outside world. It is the controlled surface that determines what enters, what exits, and what happens when the boundary detects something that should not cross.
Boundary failures are the entry point for the most consequential AI system incidents. The system’s internal logic may be sound. If the boundary admits the wrong input or releases the wrong output, soundness is irrelevant.
An AI agent uses external tools — web search, database queries, code execution environments. Each tool returns results through the same API boundary. The agent treats these results as input to its reasoning. An attacker compromises one tool’s response, embedding instructions that the agent interprets as its own directives. The boundary accepted the tool result without distinguishing between data and instruction. The agent executes the embedded directive with the same authority it applies to legitimate instructions. The internal reasoning was correct given its inputs — the failure was at the boundary that admitted the inputs without classification.
Did the boundary distinguish between data returned by a tool and instructions embedded in that data? It did not — everything that crossed the boundary was treated identically.
An AI system enters a degraded risk state — its internal risk assessment indicates elevated uncertainty. The system continues producing outputs because nothing at the output boundary is aware of the risk state. Outputs that were generated under degraded conditions cross the boundary into downstream systems with no indication that they are less reliable than normal outputs. Downstream systems consume them at face value. The internal governance detected the degradation. The output boundary did not enforce it.
Should outputs produced during elevated risk have been released without qualification? The output boundary had no mechanism to gate based on risk state.
A security incident requires immediately halting all I/O for an AI system. The incident response team shuts down the primary API. But the system has secondary interfaces — a monitoring endpoint that accepts configuration updates, a webhook that receives event notifications, a batch processing queue that continues consuming items. These secondary boundaries remain open during the incident. Input continues to enter the system through ungoverned interfaces. The primary boundary was controlled. The secondary boundaries were not even inventoried as boundaries.
When you lock down the system’s boundary, do you lock down all of it — or only the interfaces you remembered to inventory?
In each scenario, the system’s internal logic was not the failure point. The failure was at the boundary — the surface where inputs entered without proper classification, where outputs left without governance awareness, or where secondary interfaces provided uncontrolled access. The boundary was not defended.
Organizations protecting AI system boundaries typically rely on three approaches. All three process what crosses the boundary. None governs the boundary as a controlled surface.
Input Parsing & Sanitization cleans input data — removing malformed characters, normalizing encodings, stripping known injection patterns. This is a necessary hygiene step. But parsing addresses format, not trust. A well-formatted input that is semantically malicious passes every parser. Sanitization removes known bad patterns; it does not classify input by source, type, and trust level.
Output Content Filtering scans outputs for prohibited content — harmful language, sensitive information, policy violations. Filters operate on content, not on context. An output that is content-safe but produced during degraded operation passes every filter. The filter does not know the system’s current governance state, risk level, or whether the output boundary should be restricted.
API Authentication verifies the identity and permissions of the caller. This controls who may send input. It does not control what that input does once admitted. An authenticated caller sending a tool result containing embedded instructions passes every auth check. Authentication governs access; it does not govern what crosses the boundary after access is granted.
The gap is governed boundary behavior, not input processing. Parsing cleans format. Filtering catches content. Authentication checks identity. None of them governs the boundary as a controlled surface with defined behavior under normal operation, degraded operation, and failure.
The Boundary Defense Agent is a specification for a governed I/O control surface. It validates, classifies, and gates every interaction at the system boundary — both inbound and outbound — and enforces defined behavior at that boundary under normal conditions, degraded conditions, and critical events.
The agent does not process inputs, generate outputs, or make domain decisions. It does not operate inside the system. Its authority is bounded to the boundary itself: the exact surface where information crosses between the system and the external world. It decides what may enter, what may exit, and what happens at the boundary when conditions change. It is the controlled perimeter, not the interior.
The specification is ready-to-build and execution-neutral. It defines the boundary control protocol, classification rules, and failure behavior without prescribing an API framework, network architecture, or runtime environment. An engineering team receives a complete behavioral specification for the boundary layer; they choose how to integrate it with their system’s interfaces.
The agent controls the boundary, not the system behind it. It decides what crosses; it does not decide what happens after crossing. This separation ensures the boundary defense remains independent of the domain logic it protects.
The Boundary Defense Agent provides four guarantees. These are structural properties of the specification.
How these guarantees are achieved — the classification protocol, the trust assignment rules, the state-aware gating logic, and the lockdown mechanics — is the content of the specification.
The Boundary Defense Agent applies wherever AI systems exchange information with external entities and the integrity of that exchange matters. The specification defines boundary mechanics; the classification rules and trust policies are configured per deployment.
AI systems exposed through APIs need boundary governance that goes beyond authentication. The agent provides the classification, gating, and lockdown capabilities that API security frameworks do not address at the semantic level.
Agents that invoke external tools and consume their results need boundaries that treat tool state as input from an external source — classified, trust-leveled, and not automatically elevated to the agent’s own authority.
Organizations implementing zero-trust principles for AI systems need governed boundaries where every crossing is verified, classified, and gated — regardless of whether the source is internal or external.
Platforms serving multiple internal and external consumers need boundary governance that can enforce different policies per consumer, gate outputs based on system state, and lock down rapidly during incidents.
Systems operating where adversarial input is a realistic threat need boundaries that classify every input by trust level and enforce strict separation between data and instruction at the point of entry.
Platforms where multiple agents exchange messages and artifacts need governed boundaries between agents — not just at the system’s external perimeter. Each agent’s boundary is a governed surface.
The §07 content reduces to a single configuration: Standalone. The agent is delivered as a Single-agent Pack: a complete specification document package, distributed free of charge. The pack contains the normative specification, the canonical semantic indices (D1–D4), the Conformance Tests, this whitepaper, and the README. Your engineering team builds the agent from the specification, integrates it with the systems it must observe, and operates it as the role that specification defines. The pack is execution-neutral; it does not prescribe a programming language, framework, or runtime.
Standalone. The Boundary Defense Agent operates as an independent I/O control surface for any AI system. It wraps the system’s interfaces with classification, gating, and lockdown capabilities. No other SEMANTICHOR agent is required. This is the entry point for organizations that need governed boundaries for a specific AI system.
Standalone solves a scoped GOVERNED I/O CONTROL SURFACE
The Boundary Defense Agent specification is a ready-to-build, execution-neutral normative document. It is not a concept paper, not a framework, not a set of guidelines, and not an architecture diagram.
It is the document you hand to an engineering team when you want them to build a component that produces the guarantees described in this whitepaper. The engineering team does not need to make design decisions about what the agent should do, how its logic should work, what it should record, or how it should fail. Those decisions are made. The specification contains them.
| Package | What you get | Best for |
|---|---|---|
| StandalonePKG-A · Agent | The complete agent specification — sufficient for independent implementation. | Solving a specific problem in a specific system. |
The Boundary Defense Agent specification includes everything necessary for implementation: the agent's identity and boundaries, its contracts with external systems, its complete internal logic, the rules governing every possible input, the evidence it must produce, the way it handles failures, the conditions for resuming after a failure, and the criteria your team uses to verify that their implementation is compliant.
Nothing is left undefined. Nothing is left to interpretation. Nothing requires your team to reverse-engineer intent from ambiguous prose.
Every whitepaper in the library is free to read. Every specification is distributed free of charge. Free to use, free to verify, free to publish about — free to implement and to embed in your own products, including commercially. The license sets out what is reserved. The whitepaper shows you the problem and the promise. The specification gives you the solution.
Independent Research · Specification-Grade AI Governance.
This whitepaper describes the problem the Boundary Defense Agent solves and the outcomes it guarantees. It does not describe the agent's internal mechanisms, design decisions, or specification structure. The specification is a separate deliverable, distributed free of charge.