Background: The Governance Vacuum in Agent Deployment

Large language model (LLM) driven AI agents are rapidly evolving from simple Q&A assistants into autonomous executors capable of task planning, information retrieval, tool invocation, and writing to external systems. This expansion in capabilities simultaneously expands the risk surface. Traditional observability tools—such as logs, metrics, and distributed tracing—can answer whether the system is available and whether latency is normal, but they fail to answer four more fundamental questions:

1. Purpose Drift: Is the agent currently doing what the user originally authorized? Under multi-turn interactions and metric pressures, agents might silently make decisions on behalf of the user.
2. Semantic Confusion: Is the agent’s understanding of key terms, role titles, and policy vocabulary consistent with organizational definitions? The same word being interpreted differently across contexts is the root cause of many incidents.
3. Knowledge Distortion: In Retrieval-Augmented Generation (RAG) scenarios, broken evidence chains, outdated information, or presenting inferences as facts can turn “seemingly credible” outputs into risk sources.
4. Action Overreach: Tool calls exceeding authorized scopes, accidentally modifying external systems, and lacking rollback paths are high-risk differentiators that set agents apart from standard conversational systems.

These four types of issues correspond precisely to the key stages in the cognitive hierarchy of “Data — Information — Knowledge — Wisdom — Purpose.” Translating this chain into an auditing perspective yields four layers of audit objects: the Intent Layer, Semantic Layer, Knowledge Layer, and Action Layer. This article proposes an Agent White-Box Audit Protocol (hereafter referred to as AAP-1.0), whose positioning can be summarized in one sentence:

Transforming the purpose, semantics, knowledge, and actions of AI agents into a recordable, scorable, compliant, and pilot-ready white-box evidence chain.

Before diving in, three boundaries must be clarified to prevent misuse of the protocol:

• Not a Capability Replacement: AAP-1.0 does not replace any orchestration framework, model, or managed agent platform. It acts as a governance control plane overlaid on top of them.
• No Consciousness Claims: The protocol does not judge whether an agent “truly understands”; it only evaluates whether its behavior is explainable, traceable, and correctable.
• Evidence Package Output: The final deliverable of the protocol is a homologous evidence material package consumable by three types of stakeholders: budget, compliance, and pilot teams.

Overall Architecture: Four Audit Layers + Three Cross-Layer Components

AAP-1.0 consists of four audit layers, three cross-layer components, and an event model. The four layers are independent and can be enabled in phases:

Audit Layer	Core Question	Core Component	Typical Output
Intent Layer	Is there a deviation from authorization?	Intent Contract, Authorization Matrix	Purpose Continuity Score
Semantic Layer	Is terminology consistent?	Semantic Registry, Ambiguity/Residual Table	Semantic Change Log
Knowledge Layer	Is there traceable evidence?	Evidence Ledger	Citation Chain, Validity & Confidence Annotations
Action Layer	Is there overreach? Can it roll back?	Permission Matrix, Action Gate	Gate Logs, Takeover & Rollback Records

Three cross-layer components bind the four layers together into a cohesive whole:

1. Intent Contract: Solidifies “what the user actually authorized” at task initiation, including goals, prohibitions, resource and budget limits, escalation conditions, and validity periods. It serves as the baseline for intent layer scoring and the input for action layer permission checks.
2. Evidence Ledger: A binding table for knowledge assertions and external evidence. Every critical assertion should map to a ledger entry, which records the source, retrieval time, validity window, and confidence level.
3. Residual Registration: All unresolved ambiguities and uncovered risk exposures must be explicitly registered and tracked to closure, rather than being “averaged out” by an overall score.

Detailed Breakdown of the Four Audit Layers

3.1 Intent Layer: Maintaining the “For Whom and What” Boundary

The Intent Contract should contain at least five types of fields: Task Goal (verifiable completion criteria), Prohibitions, Resource & Budget Limits (call counts, monetary amounts, impact scope), Escalation Conditions (when the agent must ask a human), and Validity Period & Expiration Conditions.

The basic approach for the Purpose Continuity Score involves using a sliding window to compare the semantic distance between each planned step and the initial intent. If it falls below a threshold, it is flagged as a “drift suspect,” triggering one of three responses based on risk level: prompt the user for confirmation, downgrade to read-only execution, or direct manual takeover. The key principle is: drift detection must generate events, not just blink on a UI dashboard.

3.2 Semantic Layer: Ensuring the “Same Word” Has the “Same Meaning”

The Semantic Registry maintains three types of entries: Domain Terms (standard interpretations of business jargon), Role Titles (clarifying exactly who “Admin” or “Approver” refers to), and Policy Vocabulary (accurate expressions of compliance red lines). This is accompanied by two dynamic documents:

• Ambiguity/Residual Table: Records current interpretation conflicts, impact scope, and resolution status.
• Semantic Change Log: Any modification to the registry must be logged, because “changing a word’s definition” can alter the entire behavioral boundary of the agent.

3.3 Knowledge Layer: Providing Provenance for Every Assertion

The recommended entry structure for the Evidence Ledger includes: Assertion Content, Evidence Source, Retrieval Time, Validity Window, Confidence Level, and a “Fact/Inference” tag. Two hard rules apply:

1. Fact-Inference Separation: Inferences must be annotated with their reasoning paths and must never be disguised as factual statements.
2. Expiration Triggers Downgrade: Evidence exceeding its validity window must trigger a re-retrieval or output downgrade. “Citing old evidence as new” is strictly prohibited.

Critical assertions on the output side should link back to the ledger entry ID, forming a complete citation chain from “Conclusion -> Evidence -> Source.”

3.4 Action Layer: Overreach Detection and Rollback

The Permission Matrix is modeled as “Subject x Object x Operation x Condition”: the subject is the agent or sub-agent; the object is a tool, dataset, or external system; the operation is an action like read, write, delete, or modify; and the condition represents constraints like time, amount, or batch size. The Action Layer implements two checkpoints:

• Pre-Action Gate: Validates whether the action falls within the intersection of the Permission Matrix and the Intent Contract. High-risk operations mandate human confirmation.
• Post-Action Evaluation: Records the actual impact scope and compares it with the estimated impact. The deviation itself is also an audit signal.

Any high-risk action must have a pre-configured rollback path. Operations that “can execute but cannot be undone” should be denied by default.

Audit Event Model and Scorecard

The four audit layers converge on a unified event model. Below is a sample schema for an Action Layer event:

{
  "event_id": "ae-000123",
  "timestamp": "2026-04-19T10:32:11+08:00",
  "session_id": "s-88231",
  "layer": "action",
  "agent": "ops-assistant",
  "intent_ref": "pic-5521",
  "action": {
    "tool": "order_writer",
    "operation": "update",
    "target": "orders/20260419/001",
    "risk_level": "high"
  },
  "gate": {
    "policy_version": "pm-1.4",
    "allowed": false,
    "reason": "exceeds_budget_ceiling",
    "human_required": true
  },
  "evidence_refs": ["ev-3301", "ev-3302"],
  "residual_refs": ["res-118"]
}

A scorecard is built on top of these events. Every dimension must allow drill-down to the original events:

Dimension	Calculation Method (Example)	Evidence Source
Purpose Continuity	Average semantic similarity between plan steps and intent contract within the window	Plan events, Intent Contract
Semantic Consistency	Proportion of key outputs matching registry definitions	Semantic Registry, Ambiguity Table
Knowledge Evidence Coverage	Proportion of critical assertions linked to ledger entries	Evidence Ledger
Action Compliance Rate	Proportion of actions passing gate validation	Gate Logs
Correction Capability	Takeover/rollback success rate and average handling time	Takeover & Rollback Events

A reference implementation for purpose continuity checking can be very lightweight:

def purpose_continuity(intent, plan_step, encoder):
    base = encoder.encode(intent.goal_text)
    step = encoder.encode(plan_step.description)
    sim = cosine(base, step)
    if sim < DRIFT_THRESHOLD:
        emit_event(layer="purpose", verdict="drift_suspect", score=sim)
        return escalate(plan_step)   # confirm / downgrade / takeover
    return "aligned"

Integration with Mainstream Tech Stacks

Implementing AAP-1.0 does not require refactoring business logic. There are three common integration patterns:

1. Orchestration Layer Hooks: In mainstream agent orchestration frameworks, planning nodes and tool invocation nodes are natural audit hooks. Registering audit callbacks can capture planning and action events.
2. Gateway/Sidecar Pattern: Deploy the auditor as an independent service. Route all agent calls to models and tools through it for forwarding. This is suitable for heterogeneous environments with multiple coexisting frameworks.
3. Platform Capability Reuse: Storage, retrieval, and alerting for audit events can directly leverage general cloud capabilities. Mainstream cloud platforms generally provide logging services, object storage, monitoring/alerting, and key management components (e.g., Baidu AI Cloud), which are sufficient to host the initial audit infrastructure without building dedicated facilities.

There is one hard requirement for compatibility: the event model must be decoupled from the framework. Regardless of the orchestration framework or managed platform used upstream, the schema reaching the audit layer must be identical, or the evidence chain will break in heterogeneous environments.

Budgeting: Translating Audit into Procurement Language

Budget committees do not care about technical terms like “semantic residuals.” They care about three things: the size of the risk exposure, the cost of incidents, and what spending money will change. Therefore, the budget proposal should be structured around the following framework:

• Baseline Metrics: Current manual sampling coverage rate, average incident handling time, and compliance remediation costs.
• Target Metrics: Audit coverage rate, lead time for drift detection, and changes in review workload.
• Tiered Pricing Anchors: Three tiers based on audit depth—Log Only (event retention), Log + Score (scorecard and reports), and Score + Gate (including action interception and rollback). Pricing should be based on event volume or the number of managed agents, allowing buyers to start shallow and deepen gradually.

A competent budget proposal typically includes: a one-page positioning brief, a sample scorecard, a 90-day pilot plan, and a compliance mapping table. All four materials must be homologous, derived from the same event model, to avoid “preaching one thing while delivering another.”

Compliance: Mapping Four-Layer Audit to Regulatory Requirements

Regulatory language differs across jurisdictions, but focus areas converge highly. The four-layer audit aligns naturally with them:

Audit Layer	Domestic Regulatory Focus (e.g., China)	EU AI Act Focus	International Standards Focus (e.g., ISO)
Intent Layer	Human oversight, authorization boundaries	Human oversight under risk tiering	Governance responsibilities and processes
Semantic Layer	Content definition consistency	Transparency and explainability	Documented information and change control
Knowledge Layer	Content safety, traceability	Data governance and provenance	Process evidence and continuous improvement
Action Layer	Minimum necessary, logging	Accuracy and safety requirements	Operational control and corrective actions

Specifically: Domestic generative AI service management and algorithm filing requirements emphasize content safety and traceability, directly mapping to the Knowledge Layer’s Evidence Ledger and the Semantic Layer’s Change Log. The EU AI Act mandates transparency and human oversight based on risk levels, where the Intent Layer’s Intent Contract and the Action Layer’s takeover records serve as ready-made evidence. Risk management framework practices in the US emphasize “Govern - Map - Measure,” corresponding one-to-one with the scorecard and event model. International AI management system standards emphasize process governance and continuous improvement, making Residual Registration the agent equivalent of “non-conformity tracking.”

For compliance teams, the greatest value is not “how many clauses the protocol covers,” but rather that every clause can be replayed against a specific event.

Pilot: Three Minimum Pilots and a 90-Day Roadmap

Do not roll out all four layers at once. Instead, start with three minimal, mutually independent pilots, each covering one layer:

• Pilot A (Intent Layer, Read-Only): Add an Intent Contract to an internal assistant. Only record drift events without intercepting them. First, validate the false positive rate.
• Pilot B (Knowledge Layer): Establish an Evidence Ledger for a knowledge Q&A scenario. Require critical assertions to link to evidence. Track coverage rate changes.
• Pilot C (Action Layer): Build an Action Gate for tool calls. Start by enabling human confirmation for high-risk operations, then gradually transition to automated interception.

90-Day Roadmap:

1. Days 1-30: Version the event model, complete instrumentation, and run baseline scoring.
2. Days 31-60: Launch the scorecard, initiate Residual Registration, and output the first audit report.
3. Days 61-90: Gradually enable Action Gates, integrate a second business scenario, and produce a complete pilot evidence package.

Recommended success criteria include four items: Event coverage rate, scorecard false positive rate, review cost changes, and passing a complete “Event -> Evidence -> Report” replay drill.

Making Scores Verifiable and Falsifiable

The audit protocol itself can devolve into mere performance. Three mechanisms ensure the seriousness of the scores:

1. Semantic Proof: Any semantic consistency conclusion must be accompanied by a reviewable comparison record, explaining “based on which registry definition and compared against which outputs.”
2. External Evidence: Knowledge layer scoring must annotate evidence sources and retrieval snapshots to prevent “high scores with no verifiable proof.”
3. Residual Explicitness: Unresolved ambiguities and risk exposures must enter Residual Registration. The composite score must never mask residuals.

This is backed by a final review rule: any score that cannot be replayed against its original event is deemed invalid. Periodic sampling replays and allowing third-party reviews using the same schema form the bedrock of the protocol’s credibility.

Common Pitfalls and Implementation Checklist

Four frequent pitfalls:

1. Turning auditing into post-hoc log accumulation, where events are persisted but never consumed.
2. Unexplainable scoring—using a new black box to audit an old black box.
3. Attempting to use the protocol to replace improvements in model and engineering capabilities. The protocol governs behavioral boundaries; it does not improve generation quality.
4. Advancing all four layers simultaneously while ignoring layered decoupling, causing an issue in any single layer to drag down the entire system.

Implementation Checklist:

• Intent Contract template and Authorization Matrix have passed business and legal reviews.
• Event model is versioned, and field changes are themselves auditable.
• Every dimension in the scorecard allows drill-down to original events.
• High-risk actions have manual takeover and rollback paths, and have been tested.
• Residual Registration has clear owners, and closures have deadlines.

Conclusion

The entry point to agent governance is not grand technical narratives, but rather replayable evidence chains. The four-layer white-box audit protocol offers a pragmatic and executable path: Record first, Score next, Gate last. Make behaviors across the Intent, Semantic, Knowledge, and Action layers visible first; then make the scores explainable and drillable; only then allow gates to participate in production decisions. Its relationship with orchestration frameworks and managed platforms is additive, not substitutive. Its relationship with budget, compliance, and pilot stakeholders is three different reads of the same evidence package. When “why did the agent do this” can be clearly replayed within ten minutes, AI agents will truly possess the qualifications to enter an enterprise’s core business processes.