Why enterprise AI agents need action-level governance before they reach production

Large Language Models (LLMs) are becoming remarkably capable, to the point where more and more people use Claude, Perplexity or ChatGPT to answer questions or write code. But the moment an AI assistant gains the ability to take action, such as create a work order, update a CRM record, submit an approval request, or trigger a workflow - it stops being just an assistant.

This is where it becomes an AI agent. That’s also the moment your security model needs to change. For years, organisations have focused on prompts, model selection, and data access. But as Microsoft Foundry, Copilot Studio, and MCP (Model Context Protocol) make it easier to connect AI agents to enterprise systems, the real production question is: “What is the agent actually allowed to do?”

An AI prompt can influence behaviour, but itt should never be the mechanism that defines authority. In this article, we focus on the broader business challenge of enterprise AI authorisation.

The real risk isn’t the model, it’s the tools

Modern AI agents rarely operate in isolation, as they interact with business systems through APIs, connectors, and tools. An enterprise AI agent might:

• Read customer records from Dynamics 365
• Retrieve documents from SharePoint
• Search a Microsoft Fabric semantic model
• Create tickets in ServiceNow
• Update tasks in Jira
• Trigger workflows in Power Automate
• Call internal APIs

These integrations are what make enterprise AI agents genuinely useful, but on the other hand, they’re what make them risky. The model isn’t directly changing your business systems, but the tools you expose to it are. That’s why AI governance is rapidly shifting from model management to tool authorisation.

Why prompt rules aren’t security controls

Many early AI projects relied heavily on instructions such as: “Never modify finance records.” or “Only create maintenance requests after asking for confirmation.” These prompts help guide the model’s behaviour, but they are not security boundaries. If an agent technically has permission to perform an action, the prompt becomes little more than guidance.

Hence, production systems require something much stronger:

• Identity
• Permissions
• Policy enforcement
• Approval workflows

The prompt should define intent, and the platform should define authority.

Treat the agent’s tool surface as an authorisation boundary

One of the biggest architectural shifts in enterprise AI implementation is recognising that every tool available to an agent represents part of its authority. Instead of asking what this model can do, ask which business actions should this agent be able to perform. A good starting point is an action contract.

For every AI agent, define:

• What information can it read?
• What recommendations can it generate?
• What actions can it perform automatically?
• Which actions always require human approval?
• Which systems must remain completely inaccessible?

This creates a clear separation between capability and permission. If you would like to read about an enterprise AI roadmap, read our article called How to move from an AI prototype to production?.

Start with the smallest possible tool set

One of the simplest ways to reduce risk is also one of the most effective: only expose the tools the workflow actually needs. If an AI agent only needs to retrieve maintenance history, search approved documentation or create a maintenance request, it doesn’t also need access to finance records, supplier contracts or customer accounts. Limiting the available tool catalogue reduces both security exposure and operational complexity.

Identity should live outside the model

Every action performed by an AI agent should happen under a clearly defined identity.

That identity should:

• have the minimum permissions required
• be auditable
• follow existing enterprise access policies
• be managed independently of the prompt

Whether you’re using Microsoft Entra ID, service principals, or managed identities, permissions should always be enforced by your identity platform, not by the language model. If changing the prompt changes what an agent can access, the architecture has a governance problem.

Separate read, write, and consequential actions

Not every action carries the same level of risk, for example, reading information is fundamentally different from changing it. A useful way to design AI workflow automation is to separate actions into three categories: read actions, write actions and consequential actions. 

• Read actions

Examples:

• Search SharePoint
• Retrieve maintenance history
• Read equipment manuals
• Query Microsoft Fabric

These generally present lower operational risk.

• Write actions

Examples:

• Create work orders
• Generate Jira tickets
• Draft customer responses
• Update internal records

These should be tightly scoped and monitored.

• Consequential actions

Examples:

• Approve payments
• Delete records
• Sign contracts
• Close regulatory cases
• Modify financial data

These should almost always require explicit human approval. Human-in-the-loop isn’t simply a user experience feature, it’s one of the most important AI governance controls available.

A property operations example

Imagine a commercial property management organisation, where an AI agent receives a maintenance request. To help resolve the issue, it might:

• retrieve the building’s maintenance history
• search approved operating procedures
• identify similar previous incidents
• create a maintenance work order for review

That’s useful automation. Now imagine the same agent also has unrestricted access to:

• tenant financial records
• supplier payment systems
• lease agreements
• portfolio performance data

Nothing in the maintenance workflow requires that level of authority. The safer design is obvious: give the agent only the permissions required for that workflow, and require approval before any consequential business action is executed. That’s the difference between AI implementation and production-ready AI implementation.

Production AI requires observability

Authorisation isn’t enough, because enterprise organisations also need visibility. Every AI agent should produce an auditable record of tools calls, identitiees used, parameters, outcomes, approval decisions etc. Hence, monitoring shouldn’t only measure how successful the workflow was, it should also answer questions such as “what happened?” or “who approved it?”. 

If you would like to read an AI prototype to production case study, check out our previous article in this topic, where we helped a UK legal-tech startup bridge that gap to go-to-market with a legal workflow automation AI in Azure.

Build for change, not just launch

Enterprise AI doesn’t remain static: new business processes emerge, new APIs are added, permissions change and workflows evolve. That’s why your authorisation model should evolve alongside your AI solution. Production readiness isn’t achieved once: it’s maintained.

Review the followings just as regularly as you review the AI model itself.

• available tools
• identity permissions
• approval policies
• action catalogue
• audit requirements

Key takeaways

As enterprise AI agents become more capable, production success depends on more than model performance. It depends on identity, authorisation, approval workflows, and AI governance. If you’re building AI agents on Microsoft Azure, Microsoft Foundry, or Copilot Studio, Peruzzi can help you design secure, production-ready AI workflows that balance automation with control.