When the Agent Acts, the Enterprise Answers

Delegation Transfers Work, Not Accountability

Part 3 closed on a control plane that allows, denies, or holds an agent's action at the moment it is attempted. It is tempting to stop there — the enforcement point works, the incidents are contained, the diagram is complete. But a technical capability answers none of the questions a board, an auditor, or a regulator will actually ask. Who decided what the policies are? Who verified they are enforced — and how would you know if they stopped being? When the agent causes harm anyway, which named human answers for it?

The organizing principle is familiar from corporate governance: delegation transfers work, not accountability. Whatever legal doctrines ultimately develop around autonomous agents, the enterprise cannot treat software as the terminal owner of a consequential decision. An agent can exercise delegated authority; it cannot bear human, legal, or organizational accountability. As a governance rule, every agent action should trace through a named human owner to the enterprise operating it. An agent workforce whose actions do not trace to named humans is not an autonomous enterprise — it is an unaccountable one.

This is why the fifth domain cannot end at the control plane. The first three layers describe how the enterprise governs delegated autonomous authority mechanically. The fourth layer establishes the human structure that makes the mechanism legitimate.

Who Governs the Governor

Here is the question most agent-governance conversations skip: the control plane is itself software. Its policies are code and configuration. Someone writes them, someone changes them, and — in the failure case — someone weakens them on a Friday afternoon to unblock a launch. A policy engine with no change control is just another agent: an actor whose behavior can drift with nobody accountable for the drift.

Mature enterprises already know the shape of the answer, because they built it for other domains. Architecture review boards decide what may enter production. Change-advisory processes gate modifications to controls. Segregation of duties keeps the person who benefits from a rule change from being the person who approves it. The Governance layer applies that same discipline to the agent control plane: policy changes are proposed, reviewed by parties who do not operate the agents, ratified with a record, and versioned so that any enforcement decision can be traced to the exact policy text in force when it was made. The runtime enforces the law; this layer is the legislature and the court record.

Audit Means Evidence, Not Assertion

The second function of the layer is assurance — and the standard matters. "We have guardrails" is an assertion. Audit is evidence: demonstrating, on demand, that the enforcement machinery actually intercepts the failures it claims to. In every other control domain the enterprise learned this the hard way; controls that are never exercised decay silently, and their failure is discovered by the incident instead of the audit.

For an agent workforce, that means the governance function continuously tests its own runtime the way an adversary would — and treats the results as governance data, not engineering trivia. The practice is already executable: the initial release (April 2026) of our agent-security harness translated the problem into 332 tests across 24 modules, covering protocol integrity, decision governance, and platform-specific attack surfaces. The point is not that every enterprise needs the same harness. It is that claims about enforcement can — and should — be converted into repeatable tests whose results become governance evidence. An enterprise that cannot produce that evidence for its own agent fleet does not know its posture — it is remembering its posture from the last time someone checked.

Audit evidence also has to survive the auditor's oldest question: who watches the watchman? Enforcement logs written by the same process they judge, retention policies that let an agent's history expire before review, test regimes the operating team grades for itself — each is the assurance version of the self-asserted identity problem from Part 1. Independence is not a luxury here. It is what makes the evidence evidence.

The Regulation Is Arriving Before the Org Chart

The third function is outward-facing: mapping the enterprise's agent governance to the legal and standards landscape forming around it — a landscape that is moving faster than most organizations' internal structure.

The regulatory instruments arriving now do address AI systems and, in some cases, their operation after deployment. The EU AI Act requires high-risk deployers to assign human oversight, monitor operation, respond to serious incidents, and retain automatically generated logs. But it does not give enterprises a ready-made governance architecture for fleets of tool-using agents whose authority and behavior compose across systems — those obligations must still be translated into runtime controls and defensible enterprise evidence. The obligations exist; the operating control plane that produces that evidence is still the enterprise's to build.

The disclosure pressure is not hypothetical. AI-related control failures have already reached securities filings: in a Form 8-K, CB Financial Services disclosed that employees supplied nonpublic customer information — including names, Social Security numbers, and dates of birth — to an unauthorized third-party AI application (analysis). That was a shadow-AI incident, not an autonomous-agent failure. Its relevance here is governance: once AI-enabled conduct can expose regulated data and trigger formal disclosure, boards must know who owns the policy, who verifies enforcement, and how exceptions are detected. Agent autonomy only makes those questions more urgent — and the Governance layer is the answer prepared in advance.

What the Governance Layer Must Answer

As with the workforce layer in Part 1, five questions define the layer. An enterprise that can answer all five governs its agent workforce; one that cannot is operating on trust it has not earned.

The Four Layers, One Domain

This part closes the series, so step back and look at the whole structure. Part 0 argued that autonomous agents are not an application tier but a fifth domain of enterprise architecture. The four parts since have given that domain its layers:

The Workforce layer makes the actors legible: inventory, identity, delegated scope, lifecycle, a named owner. The Capability layer bounds what that authority can reach — because what an agent can touch is not what it is authorized to touch. The Control Plane makes the boundary real at runtime — because a rule the agent can quote but the runtime does not enforce is theater. And the Governance layer, above, makes the whole structure answerable: policy with an author, enforcement with evidence, autonomy with a name attached.

Remove any one layer and the others degrade into the failure modes this series documented. A workforce without capability bounds is an insider threat at machine speed. Capability bounds without runtime enforcement are documentation. A control plane without governance is an unaccountable governor. The four layers are not a menu. They are one domain.

This is more than a conceptual model. HRAO-E is the operating reference implementation behind the series. Its artifacts document a registered agent workforce, scoped capabilities, constitutional controls, and recorded governance decisions. That does not constitute external certification or broad enterprise validation. It shows that the architecture has been exercised in an operating environment rather than drawn only on paper.

The agent may act autonomously. The enterprise never answers autonomously. It answers through named people, versioned policy, and evidence that survives review.

About This Series

Cite the Position Paper

@misc{saleme2026eaa,
  author    = {Saleme, Michael K.},
  title     = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21105314},
  url       = {https://doi.org/10.5281/zenodo.21105314}
}