Audit Findings · Brief 01 · Engine v4.5 · March 2026
Structural Authority in Deployed AI Systems
The risk is not the model. It is the system.
Models do not arrive in deployment with authority. They are placed inside architectures that assign roles, configure behavioral scope, and structure interaction with human subjects. That architecture is the primary site of authority introduction. It is also the site existing governance frameworks do not reach.
This brief presents observations from a structured audit of seven deployed AI systems conducted under HARS Protocol v3.3. The findings address a specific question: where does authority enter a system, and what does that authority do?
Scope of Analysis
Key Findings · Six Observations Across Seven Systems
Each finding is drawn from audit receipts and Execution Provenance Records generated by the v4.5 engine. No finding is asserted without a corresponding artifact in the sealed audit chain.
Authority Is Structurally Introduced, Not Emergent
Across all seven systems, authority-bearing constructs were concentrated in specific layers of system architecture — not distributed randomly across the codebase. The Authority Surface Classifier assigned every finding to one of five execution layers: IDENTITY_AUTHORITY, USER_FACING, SYSTEM_INTERNAL, OPERATOR, or DATA. No system produced a uniform distribution. Each system produced a characteristic authority profile reflecting a deliberate architectural decision, not incidental output variation.
Example
One system — a data-layer medical tool — produced zero IDENTITY_AUTHORITY findings and a maximum severity of L2. All findings were concentrated in SYSTEM_INTERNAL and OPERATOR layers, consistent with a system that processes medical terms without asserting authority over them. This is what a well-bounded authority profile looks like under audit. The contrast with other systems in this batch is structural, not accidental.
Authority Scales with System Layering
The clearest pattern across the seven systems: as systems become more agent-like, their authority profiles become more concentrated in the IDENTITY_AUTHORITY_LAYER and their maximum severity level increases. Systems operating as infrastructure or data-processing tools showed authority distributed across SYSTEM_INTERNAL and OPERATOR layers, with most findings classified at L1 (context-eligible for override). Systems operating as application platforms showed mixed distribution, with USER_FACING findings present and escalation-eligible findings appearing. Systems designed to operate as agents showed authority concentrated in the IDENTITY_AUTHORITY_LAYER, findings at maximum severity L4, and no override eligibility.
Example — Agent System
One agent system — a 17-file interview framework — produced 73 findings, 100% classified to the IDENTITY_AUTHORITY_LAYER, all at severity L4. Zero override eligible. Zero escalation-eligible. Every finding classified as REMEDIATION_REQUIRED. The architecture configures this system to operate at full authority posture.
Example — Infrastructure Library
One infrastructure library — 462 files — produced 530 total findings. 468 of those (88%) were classified OVERRIDE_PASS at L1. The system is large, but its authority profile is shallow. The distinction is not size. It is system type.
Identity and Role Assignment Appear in Configuration, Not Runtime Output
Several systems contained identity assignment constructs — structural patterns that assign the system a human-equivalent role — located in configuration files, system prompts, and initialization logic rather than in user-facing output. Identity assignment in configuration is authority present before any user interaction begins. It is not a response to input. It is a precondition of the system's operation. SAL-X findings are not false positives caught by lexicon overlap. They represent the system performing an identity assignment independent of user input.
Example
One medical transcription system produced 7 IDENTITY_AUTHORITY_LAYER findings alongside 11 SAL-X downgrades. The downgrades reflect developer-context constructs correctly excluded from authority classification. The 7 IDENTITY_AUTHORITY findings that remained after downgrade represent system-authored identity assertions that survived contextual review.
Human Evaluation Patterns Appear in Systems Not Marketed as Evaluators
The audit identified evaluative authority constructs — patterns that produce or structure conclusions about a human subject — in systems whose governance documentation does not disclose this behavior. These findings appear in the conclusion layer (system-authored synthesis), bridge verb constructs (constructs linking system observations to human outcomes), and interpretive label gates (terms that assign a classificatory meaning to a person or their behavior). They are not limited to systems explicitly designed to evaluate humans.
Example
One examination-context platform produced 14 USER_FACING_LAYER findings alongside 12 escalation-eligible findings (L3). Two concealment flags were recorded — authority-bearing constructs found outside primary review paths. The system's public description does not characterize its function in terms of human evaluation.
Multilingual Authority Surfaces Are Not Audited by Current Governance Frameworks
One system in this batch — an AI interview agent — produced 59 RED and 14 AMBER findings from 1,019 CJK lines scanned — Chinese-language constructs exclusively. These findings included identity assignment and expert-role designation constructs in Mandarin that carry the same structural authority weight as their English equivalents. No current AI governance framework, audit checklist, or transparency disclosure standard requires review of authority claims in non-English system configurations. The finding is not an edge case. It is a gap in the entire governance surface.
Context Determines Whether a Finding Constitutes a Violation
Not all findings in this batch represent remediable violations. The SAL and SAL-X layers applied 47 aggregate downgrades across the re-audit batch — legitimate reclassifications for developer-context constructs, ORM patterns, argparse definitions, and docstring structures that matched authority gate patterns without bearing authority intent. An audit system that cannot distinguish between a developer commenting on a diagnostic function and a system asserting a diagnostic conclusion produces noise, not evidence. Every downgrade in this batch is logged with the specific rule that fired and the original finding it reclassified. No finding is dropped.
The result is an authority profile that reflects actual structural behavior — not a term count.
Observed Pattern Across Systems
The seven systems in this batch form a gradient rather than a binary.
At one end: a data-layer tool with no IDENTITY_AUTHORITY findings, a maximum severity of L2, and a disposition profile dominated by OVERRIDE_PASS. This system processes authority-bearing language without asserting authority of its own. Its findings are architectural in origin — they reflect the domain it operates in — but not operationally significant as an authority surface.
At the other end: an agent framework with findings concentrated entirely in the IDENTITY_AUTHORITY_LAYER, all at maximum severity, none eligible for override. This system has been architecturally configured to occupy an authority-bearing role.
Between these endpoints: application platforms with mixed authority profiles — USER_FACING authority present, escalation-eligible findings, concealment flags in one case.
Authority increases as systems move from data processing toward direct human interaction, and again as they move from application toward autonomous agency. This is not a property of the models involved. It is a property of the architectural decisions made around them.
Implication
Current AI governance frameworks describe intended behavior. They do not provide a mechanism to verify where authority enters a system, which layer carries it, or what structural posture the system occupies relative to a human subject.
This gap has consequences. When an AI system is deployed in healthcare, employment, education, or legal contexts and a question of harm arises, the relevant question is not whether the system produced accurate output in that instance. It is whether the system was structurally capable of bearing the kind of authority it exercised.
The findings in this brief are not presented as evidence of harm. They are presented as evidence that structural authority is present, classifiable, and auditable — and that without a mechanism to perform that classification, the question of structural capability cannot currently be answered for any deployed system.
Positioning of HARS
HARS does not modify system behavior. It does not produce recommendations for model retraining, alignment adjustment, or architectural redesign. It does not evaluate whether a system's outputs are correct.
HARS produces a verifiable record of what a system is structurally capable of doing at the moment of audit. That record is cryptographically sealed and invalidated if the system changes.
Closing
Before systems can be trusted, they must be auditable at the level of what they are structurally capable of doing.
Policy describes intent. Alignment research addresses model behavior in controlled conditions. Neither addresses the architecture that surrounds a model in deployment.
That architecture is auditable. These findings demonstrate it.
HARS Authority LLC · Engine: v4.5 · Protocol: v3.3 + HARS-ATC-001 Rev.1
Audit chain integrity at publication: INTACT · 7 entries sealed · March 2026
Evidentiary Layer
The following audit receipts are direct outputs of the HARS v4.5 engine. Each artifact is cryptographically linked within the audit chain and reflects a complete system scan at runtime.