Your AI Agent Can Read Everything. Should It Be Able to Change Anything?

Every vendor demo right now shows the same thing: an AI agent that can answer questions about your environment. Who has access to this site? How many guest accounts are stale? Which groups haven’t been reviewed this year? It’s genuinely useful and the major platforms are racing to provide it. And even where enterprise agents are initially constrained to read-only scenarios, the direction of travel is obvious.

That direction is the whole story.

Reading is the easy half. The half that actually changes how IT works, the half nobody has cleanly solved, is letting an agent do something. “Add this person to that security group.” “Provision a workspace for the new project.” “Offboard the contractor who left on Friday.” The moment an agent can take an action that mutates your tenant, every comfortable assumption from the read-only world stops applying.

Why “just let it call the API” is the wrong answer

The tempting shortcut is to hand the agent the keys: give it write permissions and let it call the underlying APIs directly. This fails in three predictable ways.

It’s non-deterministic where it can’t afford to be. Onboarding a user is rarely one call. It’s create the account, assign the licenses, add the group memberships and apply the policies, in that order. An agent improvising that sequence from natural language might create the account, succeed on three of five steps and leave you with a half-provisioned identity and no clean way back. Composition, ordering and rollback are not things you want an LLM reinventing per request.

It has no notion of “this one needs a human first.” Adding someone to a project team and adding someone to a privileged admin group are the same shape of API call. They are not the same shape of decision. A direct-to-API agent treats them identically unless every guardrail is baked into the prompt, which is to say, unless there are no reliable guardrails at all.

It leaves no defensible trail. When an auditor asks what changed last Tuesday and who authorised it, “the agent decided to” is not an answer. Direct API access scatters the evidence across service logs that were never designed to reconstruct intent.

The principle: the agent proposes, the platform disposes

There’s a better separation of concerns and it’s an old one wearing new clothes. The agent’s job is to understand intent and propose an action. A separate, deterministic execution layer’s job is to decide whether and how that action actually happens.

Concretely, the agent never touches the underlying API. It calls a curated business verb, such as add group member, provision workspace or offboard user and that verb is owned by a platform that does the unglamorous, essential work: it validates the request against a strict contract, evaluates policy (is this a privileged target? does this need approval?), executes the steps deterministically and idempotently, retries or safely parks on failure, writes status back and records every step against a single correlated trail.

Make that tangible. Suppose the agent proposes:

request_group_membership(user, group, justification, duration)

The agent has done its job: it understood the intent and filled in a structured, contract-shaped request. What happens next is not the agent’s decision. The platform looks at the request and decides, by policy and not by prompt, whether it is auto-approved for a low-risk group, routed to the group owner for sign-off, blocked outright because the target is privileged, granted only for the requested duration and then automatically revoked, logged for audit and scheduled for later review. Same verb, very different outcomes, all governed in one place.

This is not about replacing ServiceNow, Jira or your internal workflows. It is about making agent-initiated requests enter the same governed channels as every other enterprise change, so an action proposed by an AI is held to exactly the standard as one raised by a human in a service catalog.

The agent becomes the natural-language front door. The platform remains the system of record for what is allowed to happen and how. The intelligence proposes; the governance disposes. Crucially, this also means your guardrails live in one auditable place rather than being re-litigated inside every prompt and they apply identically whether a request arrives from an agent, a service catalog or a scheduled job.

Two principles that should be non-negotiable

If you build this layer, two design commitments separate a serious platform from a demo.

Lifecycle is designed in, not bolted on. Most automation is good at creation and silent about retirement. That asymmetry is exactly how tenants accumulate thousands of orphaned groups, abandoned sites and guest accounts nobody owns. The discipline that fixes it is simple to state and hard to retrofit: no ability to create a kind of resource ships without the matching ability to retire it and every resource is born with an owner, a review date and, where it makes sense, an expiry. Provisioning is what vendors demo. Governed retirement is what auditors ask about and what overgrown environments are quietly drowning in.

No standing accounts in the automation path. An execution layer that runs on a service account with a stored password has simply moved the risk, not removed it. That credential leaks, expires or outlives the person who created it. The modern bar is managed and workload identities throughout: federated, scoped to least privilege, with no secret sitting in a config file anywhere. For regulated organisations this isn’t a nicety; it’s frequently the line between “approved” and “not in our tenant.”

Where this is heading

Agents that can safely act, not just read, will be the difference between AI that’s interesting and AI that does the work. But “safely” is carrying enormous weight in that sentence and it isn’t a property of the agent. It’s a property of the layer the agent talks to.

That layer is the direction we are building toward at SPEX: a code-first automation platform that runs entirely in your own tenant, exposes governed business actions rather than raw API access, builds lifecycle into every one of them and runs without a single standing credential. It’s how an organisation gets to say yes to agent-driven IT without giving up the controls that let it sleep at night.

The agents are coming either way. The question worth answering first is what they’re allowed to touch and what stands between a good intention and an irreversible change.

---

Thinking about agent-ready automation for a Microsoft-centric, regulated environment? Talk to SPEX.