AI Governance
AI Agents Can Act for Your Business. Who Is Accountable When They Get It Wrong?
If software can send messages, change records or trigger a transaction, the business needs a named owner, clear limits and evidence of oversight.
7 min read — Altitude IT Support
An AI assistant that suggests a draft is different from an agent that can send it, update a customer record or start a payment workflow. As systems gain access to business applications, the decision to delegate work becomes an IT governance decision: somebody must define the task, approve the access and remain accountable for the outcome.
A military announcement is context, not a business forecast
Reporting in September 2026 described Pentagon plans for an Autonomous Warfare Command intended to coordinate work on autonomous systems. The proposed command was not yet an operating organisation, and military systems are a different subject from a commercial AI agent. The useful connection for a business is narrower: when technology is given more ability to act, speed does not remove the need to define who controls it and who can intervene.
Give every agent an accountable business owner
Before enabling a workflow, name a person responsible for its purpose, access, testing and ongoing review. That owner should know which supplier operates the system, what identity it uses, which data it can read or change and which other services it can call. If the agent is no longer needed, the owner must be able to pause it and arrange removal of its credentials, application permissions and connected accounts.
Do not assume every product uses the same technical model. One agent may act through a named user account, another through an application identity and another through a supplier-managed service. Ask the provider to show the actual permissions and activity records for the chosen configuration. In Microsoft Entra ID, for example, application registrations, delegated permissions and access reviews can be relevant, but the right evidence depends on the product architecture.
Decide which actions need human approval
Separate low-impact preparation from actions that create a commitment. An agent might draft a response or assemble information for review, while an employee approves an external message, changes a supplier's bank details or authorises a financial transaction. Approval only counts as oversight when the person can understand what is proposed, has enough context to challenge it and can stop it before the action occurs. A routine confirmation button that staff are expected to click without review is not a useful safeguard.
Set boundaries for ambiguous instructions, unusual requests and missing information. Define what the system must not do, what causes it to ask for help, how actions are logged and who receives an alert. For high-impact processes, test attempts to bypass the workflow and confirm that a user cannot simply grant the agent broader access without an approval trail.
Evidence to request from your IT provider
- An inventory of agents and automations, each with a business owner and approved purpose.
- A diagram or record of the identities, applications, data stores and permissions used by each agent.
- The limits on actions, the approval points and examples showing that the approval can be withheld.
- Logs that identify the agent, the request, the action and any human approval or override.
- A tested procedure for pausing the workflow, revoking access, investigating activity and restoring manual operation.
Check whether log retention is sufficient for the business to investigate a disputed action. Ask how supplier changes affect permissions and whether the organisation is notified when a connector or capability changes. For a Microsoft 365 integration, include application permissions and tenant access in the review; for another platform, ask for its equivalent evidence rather than assuming the same controls apply.
Introduce autonomy in stages
- Choose a bounded, low-risk task with a named owner and a way to measure success.
- Start with the smallest required access and avoid long-lived privileges where the platform supports safer alternatives.
- Test normal requests, ambiguous cases and failure scenarios before allowing live actions.
- Require a person to approve actions whose impact would be difficult to reverse.
- Review logs, permissions and business value, and practise stopping the agent.
The NCSC recommends careful, incremental adoption and says organisations should be clear about ownership, access, monitoring and who can stop an agent. This complements Altitude IT's existing guide to identity and least-privilege controls for AI access: this article focuses on who accepts responsibility for actions and how approval works. Would you give a new employee unrestricted access to your business systems? Then why give it to an AI agent?