Agentic Information Barriers

Purpose

This document introduces agentic information barriers as a category descriptor for runtime and record-custody arrangements that separate what an AI agent generates from what an institution admits onto its record. It explains how that category relates to ARCS and where ARCS does and does not have something to say.

The document is informative. It is not part of the normative ARCS standard, it does not certify any product, and it does not endorse any vendor.

Category descriptor, not a product class

"Agentic information barrier" (AIB) is used here as a descriptive label for a class of governance arrangements with two recurring properties:

• An AI-agent action surface — for example, a tool call, a generated draft, a retrieval, a delegation, or an outbound message — is treated as a boundary that may need to be governed.
• That boundary is paired with a record-custody posture that decides whether evidence of the action is preserved, where it persists, who holds it, and how it can later be reconstructed.

The term is a category descriptor. It does not name a single product, a single specification, or a single regulatory regime. Different operators may implement agentic information barriers using different runtime systems, different policy vocabularies, and different evidence pipelines.

Runtime governance and record custody

It is useful to distinguish two layers that often get blurred when people discuss "AI controls":

• Runtime governance decides what an agent is permitted to do at the moment of action: whether a tool call proceeds, whether a draft is sent, whether a delegation is honored, whether an approval is required.
• Record custody governs whether and how evidence of that runtime decision — and of the surrounding interaction — exists, persists, and can be produced later.

Runtime governance produces evidence. Record custody governs the surface that evidence enters. An agentic information barrier, as the term is used here, spans both layers: it includes the runtime boundary discipline and the record-custody posture that makes the boundary auditable after the fact.

ARCS is a record-custody framework. It does not specify a runtime policy engine and does not prescribe how any particular agent action must be evaluated at runtime. ARCS governs the record surface that runtime governance produces.

Why AI-agent actions create record surfaces

Agent runtimes increasingly externalize governance evidence during ordinary operation. A single agent action may produce:

• policy decisions and approval records,
• audit events, trace identifiers, and integrity proofs,
• identity, trust, and delegation artifacts,
• retrieval, source-access, and tool-invocation events,
• generated drafts, intermediate artifacts, and outbound message candidates,
• denial reasons, reviewer tasks, and operator-context fields.

Each of these is a record. Each has lifecycle, custody, publication, preservation, non-creation, and verification posture. The fact that an action was denied, gated, advised against, or simply observed does not eliminate the record surface — it shapes it.

Two boundary principles already articulated in the ARCS context layer apply directly:

• Denied actions still create records. A blocked action may produce policy decisions, audit events, trace identifiers, reviewer tasks, denial reasons, and integrity proofs.
• Non-retention is not non-existence. An operator may configure a runtime not to retain payload bodies; that posture does not eliminate residual artifacts such as hashes, timestamps, trace identifiers, audit receipts, billing events, routing metadata, and provider telemetry.

These principles are why an agentic information barrier is not complete without a record-custody account.

Implementation modes are not ARCS requirements

Runtime governance over agent actions is commonly implemented in one of three modes, often described as:

• Observe. The runtime records that an action occurred and emits evidence, without altering the action.
• Advisory. The runtime surfaces guidance, warnings, or recommended alternatives, while leaving the action to proceed or be reviewed by a human.
• Enforcement. The runtime gates the action — for example, by requiring approval, modifying the request, or refusing to proceed — where host hooks support it.

These modes describe how an operator may implement a barrier over supported, in-scope agent actions. They are not ARCS controls and ARCS does not require any particular mode. Whether a given runtime can offer a given mode for a given action depends on the host environment, the agent framework, the tool surface, and the operator's configuration.

ARCS's interest in these modes is downstream: each mode produces a different mix of records, and each of those records has lifecycle and custody posture that ARCS control families address.

What ARCS governs and does not govern

ARCS governs record-custody posture. In the context of agentic information barriers, this means ARCS addresses questions such as:

• Which records exist as a result of a governed agent action.
• Where those records persist, including across operators, vendors, and local environments.
• Who holds custody at each surface.
• What lifecycle, publication, preservation, non-creation, and verification posture applies.
• How portable evidence (for example, an SRS-style receipt) can carry boundary information across systems.

ARCS does not:

• specify a runtime policy language for agent actions,
• mandate observe, advisory, or enforcement mode for any action class,
• certify any product, vendor, or implementation as an "ARCS information barrier,"
• constitute a legal opinion or regulatory certification.

An implementation that describes itself as an agentic information barrier may be ARCS-aligned to the extent that its record-custody posture is consistent with ARCS control families. It is not, by virtue of that description, ARCS-certified or ARCS-required.

Relationship to runtime-governance evidence producers

Runtime systems that emit governance evidence — for example, agent governance toolkits, policy engines, MCP security layers, audit sinks, and approval workflows — are evidence producers from an ARCS perspective. The ARCS-Microsoft-AGT Crosswalk gives a worked example of how one such evidence producer maps onto ARCS record-custody slots.

Other implementations of agentic information barriers may produce similar evidence: policy decisions, approval records, integrity proofs, identity and delegation artifacts, trace identifiers, and portable receipts. Where those evidence types map cleanly onto ARCS, SRS, and Reconstructor structures, they can be treated under the same record-custody discipline. Where they do not, the gap is itself a record-custody finding.

Specific products may be referenced as illustrative examples of agentic information barrier implementations. Such references are illustrative only. They do not make any product an ARCS requirement, and ARCS does not become vendor- or product-specific by being implemented in any particular system.

Practical reading

An agentic information barrier, as the term is used here, is a governance arrangement that:

• treats supported, in-scope AI-agent actions as a runtime boundary,
• selects one or more implementation modes (observe, advisory, enforcement) for those actions where host hooks support it,
• produces governance evidence at the boundary, and
• maintains a record-custody posture over the resulting records.

ARCS governs the record-custody posture. Other frameworks, products, and operator policies govern the runtime boundary itself. The two layers are complementary, and an effective agentic information barrier needs both.

Deferred work

A later context document may describe a recommended evidence profile for agentic information barrier implementations that wish to interoperate cleanly with ARCS-aligned reconstruction and verification tooling. That profile is not part of this explainer.

ARCS v1.0 | Agentic Information Barriers (informative) | arcsstandard.org