As businesses move AI agents into real workflows, the challenge for technical leaders is becoming less about what these systems can do and more about what they should be allowed to do.

Imagine hiring a new engineer and, on their first day, giving them access to your customer database, internal documents, cloud infrastructure, financial systems and production environment. You would expect a few questions before granting those permissions. What do they need access to? Who approved it? What could they change? Who is accountable if something goes wrong?

Now consider an AI agent built to handle a seemingly straightforward task. It might need to read documents, query a database, call internal APIs and update a record in another system. Connecting those tools can make the agent considerably more useful, but it can also give a piece of software the ability to act across parts of the business that were never designed to work together without human oversight.

That is becoming one of the more important challenges in enterprise AI. Businesses are getting better at building agents capable of carrying out multi-step tasks, while the questions around identity, permissions and accountability are catching up.

The problem starts when an agent can act

An AI assistant that recommends a change is relatively easy to reason about. A system that makes the change itself introduces a different set of risks.

An agent might be asked to investigate a customer issue, identify the cause and resolve it. To complete that task, it could retrieve customer information, inspect application logs, query internal systems and initiate an action. Each step might appear reasonable in isolation, yet the overall process could expose sensitive information or make a change that should have required approval.

The difficulty is that an agent's behaviour can depend on the information it encounters along the way. Instructions embedded in a document, unexpected data or a tool returning an unusual result can affect what it attempts to do next. A system that was given broad permissions for a legitimate purpose may therefore have more authority than it needs for the task it is currently performing.

Microsoft's October 2026 guidance describes agents as a potential insider risk, highlighting the importance of giving them distinct identities, limiting their permissions and monitoring what they do. The underlying principle is straightforward: a model's ability to reason should not determine its authority to access or change business systems.

This matters because the more useful agents become, the more likely businesses are to connect them to valuable infrastructure. The security model needs to develop alongside that capability.

The next challenge is deciding where autonomy stops

For a technical leader, the answer cannot be to require human approval for every action. That would undermine much of the value of automation. Nor is it sensible to allow an agent to operate freely because it has performed well in testing.

The more practical approach is to define boundaries around the work itself. An agent might be allowed to read production logs but not modify infrastructure. It could prepare a database change, with a human approving the final execution. It might resolve routine support requests automatically while escalating cases involving sensitive customer data or financial consequences.

Those boundaries need to exist in the architecture, rather than relying on the model to remember its instructions. Permissions should be limited to the task, consequential actions should have clear approval requirements, and the system should maintain an auditable record of what happened.

This creates a design question that spans several teams. Engineering needs to make the agent useful and reliable. Platform teams need to control its access to infrastructure and internal tools. Security needs to establish policies that remain effective when the agent behaves unexpectedly. Product and business leaders need to decide which actions can be automated and which require human judgement.

The decisions are connected, and leaving them to separate teams without clear ownership is likely to create gaps.

This changes the people businesses need

There is a hiring implication here that deserves more attention. As companies move from AI experiments to agents operating inside real workflows, they need people who understand the interaction between AI systems and the environments in which those systems run.

That includes platform engineers who can build controlled execution environments, security engineers who understand machine identities and fine-grained permissions, and AI engineers who can design systems with appropriate limits on tool use. It also increases the importance of technical leaders who can bring these disciplines together and make clear decisions about risk.

These capabilities will not always sit in separate roles. In a smaller business, an experienced platform or AI engineer may own several parts of the problem. In a larger organisation, identity, cloud security, AI infrastructure and application engineering may each have a defined responsibility. The right structure depends on the complexity of the systems and the consequences of an agent getting something wrong.

The important hiring decision is to identify who will own these controls before an agent becomes business-critical. A company can recruit excellent AI engineers and still leave a serious gap if nobody is responsible for how their agents access systems, how permissions change over time or how actions are investigated after an incident.

That responsibility should be reflected in job specifications, team structures and technical leadership discussions, rather than being treated as a security review at the end of a project.

AI deployment needs an ownership model

The next stage of enterprise AI will require more than teams that know how to build capable agents. It will require teams that can give those agents access to the right information, constrain their actions, monitor their behaviour and take responsibility for the outcomes.

For hiring managers, that means looking closely at the operational side of AI capability. Can the team explain which systems an agent can access and why? Can it limit that access when a task changes? Is there a clear owner for approving high-impact actions? Can the business establish what happened when an agent makes an unexpected decision?

These are engineering and organisational questions as much as security questions. They influence architecture, delivery, team design and the skills required to move AI into production safely.

At Tides, we work across AI, data and engineering, where the decisions businesses make about technical capability ultimately shape what they can build and deploy. As agentic systems become part of everyday operations, understanding the people required to govern and operate them will be an increasingly important part of building an effective AI team.