Enterprise AI needs boring controls

Enterprise AI conversations keep inventing new language for controls we already understand.

The model is new. Fine. Most of the operational questions are not.

Who is acting? What may they access? What may they change? How do we test the behavior? What gets logged? Who approves the risky part? How do we stop it?

Boring questions. Good questions.

Identity comes before intelligence

An enterprise agent should not operate as a generic super-user because that is convenient for the prototype.

Give the agent its own identity. Scope credentials to the job. Separate read access from write access. Keep customer, employee, payment, and operational data behind the same boundaries that apply to other applications.

If an agent acts on behalf of a person, preserve both identities: who asked and which agent executed. That distinction matters when the action crosses systems or creates a financial consequence.

The model can reason about policy. Enforcement should still happen in the systems that own access and transactions.

Limits are part of the design

An agent needs ceilings.

That might be a refund amount, number of records changed, environments it can deploy to, tools it can call, or rate at which it can act. High-impact operations may need a person to approve the proposed action before execution.

These limits should be explicit and testable. “Be careful” is not a control. It is a request.

The right limits depend on reversibility. An agent can have more freedom when the outcome is cheap to inspect and undo. Irreversible or regulated actions deserve a narrower boundary even if the model appears consistently correct.

Evaluation is regression testing for behavior

Models are probabilistic. Enterprise teams still need to know whether behavior improved or regressed after a prompt, model, tool, policy, or data change.

Build a set of representative cases. Include normal requests, ambiguous requests, missing data, prohibited actions, prompt injection attempts, downstream failures, and cases that should escalate.

Then run them as part of the change process and record the outcome.

An evaluation score is not a guarantee. It is evidence. The useful part is seeing which behavior changed and whether the remaining failures are acceptable for the authority the agent has.

If the agent can only be evaluated through a live demo, the system is not ready for consequential work.

Logs need to reconstruct the action

Do not log everything just because it exists. That creates privacy and security problems with very expensive search.

Log enough to reconstruct the decision path:

• request identity and correlation ID
• model, prompt, policy, and tool versions
• sources retrieved
• proposed and executed actions
• validation and approval results
• downstream transaction identifiers
• final status and exception path

Sensitive content should be minimized or redacted. Auditability and data hoarding are not the same thing.

Build the stop button early

The system needs a reliable way to disable an agent, a tool, or a class of actions without waiting for a full release.

That control should be tested. So should credential revocation, queue draining, and recovery of work already in progress.

Nobody wants to discuss the kill switch during the demo. That is probably why it belongs in the architecture review.

Governance should make delivery possible

Good controls do not exist to turn every AI change into a committee meeting. They create a safe operating envelope so the team can move quickly inside it.

Clear authority, scoped access, automated evaluation, transaction limits, useful logs, and an escalation path reduce the number of decisions that need to be reinvented for every use case.

The model will keep changing. The control plane is how the enterprise avoids starting the trust conversation from zero every six weeks.

None of this is glamorous.

Good. Boring is what I want from the part that keeps an agent from moving money twice.