The previous blogs described the technical architecture: structured outputs, targeted information selection, execution control, data protection, and quality assurance. What's still missing is the organizational side: Who is allowed to do what — and who bears the responsibility when an AI agent makes a decision?
The Problem: An Agent is Not a User
Classic authorization systems are designed for human users: A person logs in, performs an action, logs out. The system logs who did what.
An AI agent breaks this model. It doesn't act once, but in sequences — it plans, executes, observes, re-decides. It can interact with dozens of systems in seconds. And it makes decisions not based on explicit rules, but on learned patterns. A standard authorization system cannot map this without adaptation.
„In the worst case, an AI agent without an authorization concept has access to all data — and no awareness of which of it it is allowed to use."
Three Levels of Governance
Level 1 — Technical Guardrails: The first five blogs described this level. Structured outputs limit what the agent can produce. Attempt limits and monitoring layers restrict what it is allowed to execute. The hybrid architecture limits which data it can see at all. Quality assurance ensures that it does all this consistently.
Level 2 — Organizational Roles: Technical guardrails alone are not enough, because they must be defined, maintained, and monitored by someone. Four areas of responsibility are essential:
- The Process Architect defines which goals an agent may pursue and which actions are permissible for that.
- The Semantic Specialist maintains the knowledge base from which the agent draws its information.
- The Supervisory Manager is the human point of contact who intervenes if the agent escalates.
- The AI Compliance Officer ensures that data protection requirements, legal regulations, and internal guidelines are adhered to.
Level 3 — Company-wide Control: If every department operates its own agents, its own knowledge databases, and its own access data to cloud services, an uncontrollable tangle emerges. A central governance structure defines who may introduce agents, how they must be documented, and how exceptions are handled.
Practice: The Smart Hub Case with an Authorization Lens
In the warranty case of Markus Meier, the agent needs read access to customer master data, product information, and internal memos — but no write access to the ERP system as long as the regional manager's approval is pending. The authorization structure must reflect exactly that: narrow, clearly defined access, logged process.
The approval itself is not a technical problem. It is a business decision — and that is made by the regional manager, not the agent. The task of the architecture is to cleanly map this handover point.
Anyone who gives the agent the full write access of a clerk is saving in the wrong place. The risk is not the model — it is the lack of clear demarcation of access rights.
Overview: The Seven Concepts of the Series
| Blog | Topic | Concept |
|---|---|---|
| 02 | Structured Outputs | Mandatory output schemas for all model responses |
| 03 | Information Selection | Targeted access to relevant information instead of full-text search |
| 04 | Execution Control | Attempt limit, monitoring layer, and escalation path |
| 05 | Data Protection | Local preprocessing, cloud decision, re-enrichment |
| 06 | Quality Assurance | Test dataset and automated testing with every change |
| 07 | Governance | Permissions, roles, and company-wide control |
Conclusion
Autonomous agents need not only technical guardrails but also clear organizational structures. Who defines what the agent is allowed to do? Who intervenes if it escalates? Who is responsible if it makes a wrong decision? Without answers to these questions, every production deployment remains a calculated risk.
Blog 08 brings all seven concepts together and shows how they function as a system.
The prompt is just the beginning. Permissions and governance are the foundation of production operations.