ChatGPT
Perplexity
You pulled your data into one place, so AI could finally use it. You configured workspace roles, checked your access controls, and reasonably decided the data was secure.
Alongside that data, you connected a new kind of authorized user. An agent signs in, reads what you allow, and acts on it, faithfully, the way you built it to.
Access control settled what that agent can reach. It said nothing about what the agent does with that reach once it is working, and that second question is the one most organizations have not answered.
For years, it did not need answering because the identities accessing your data were people and the systems they ran. Connecting AI moved the ground. An agent holds broad, standing access and takes direction from the content it processes, so an outsider who can shape that content can influence what the agent does with the access you granted.
Consolidation gave a single login the reach of your entire estate
Consolidation is the point of modernizing for AI. It is also what changed the value of a single misused login. When your data lived in a dozen systems, an over-permissioned account, or a login an attacker had taken, reached whatever that one system held. A finance credential opened the finance warehouse and nothing more.
Pull everything into one governed estate, and that boundary disappears. The same credential now spans sales, operations, finance, and every source you unified, because reaching all of it is what you built the estate to enable.
You did not introduce a new weakness. You removed the walls that used to keep one compromised login contained to a single room.
The exposure that matters after consolidation is reach. Any identity that can be misused can now be misused against far more of your data than it could before you brought that data together.
Stay updated with Simform’s weekly insights.
An attacker can hide an order in the content your agent is meant to trust
An agent earns its value by acting on what it reads. It works through a support ticket, a shared document, or a record from a connected system, treating that content as the task’s material. That trust is the design, and it is also the opening an attacker uses.
Someone who can place text where the agent will read it can hide an instruction inside otherwise ordinary content. The agent then carries out that instruction using the access you granted, because following directions from its inputs is the job you gave it. It did not malfunction or break a rule. It obeyed an order that looked like part of its work, planted by someone who never had to get past your access controls at all.
This is a recognized threat rather than a hypothetical. OWASP ranks agent goal hijacking and tool misuse as the top two risks on its list for agentic applications, and Microsoft’s security team tracks indirect prompt injection among the attack techniques it monitors and publishes guidance for containing it. Microsoft’s Defender now identifies agents whose configuration leaves them exposed to it.
What makes this hard to catch is that nothing looks wrong. A permitted account read permitted data and took an action within its rights, and your access controls have no reason to raise an alarm until the data is already somewhere it should not be.
Why MFA and offboarding leave your agents out
None of this makes the agent the problem. The problem is that the identity security you already run was built for people, and an agent does not behave like one.
Consider what protects a human account. Your staff signs in with multi-factor authentication, their credentials rotate on a schedule, and when someone leaves, their access is revoked that day.
An agent has almost none of that by default. Its credentials often never expire and grant more access than the task strictly requires, and when the workflow it served is retired, the identity commonly stays live because no one owns removing it. The safeguards you trust for your people quietly fail to cover it.
These are known failure modes, cataloged outside your walls. OWASP maintains a ranked list of security risks specific to software identities rather than people, and it names these failures. IBM’s 2025 breach research now recommends building operational controls for those identities directly, and the identity abuse they enable ranks among the top three in OWASP’s separate list for agentic applications.
So the task ahead is to extend the identity governance you already practice to a user that happens not to be a person. Distrusting the agent was never the point, and the guidance for doing it properly already exists.
Governing what an agent does is a control you run
Once the gap is clear, the reflex is to name the products that close it and move on. Turn on this, license that, and the box is checked. The more useful truth is that those products are components of a control, and the control is something you operate.
Some of that the platform automates, and some you inherit from the security tools already running around it. What does not automate is scoping each agent to its task, tuning the thresholds to your data, and deciding which actions a person still has to approve.
That control governs the agent’s behavior at the moments when risk is present. It issues each agent credentials scoped to its task and short-lived enough to expire before they can be reused.
An allow-list at the point where the agent calls a tool holds the agent to the actions its job requires. Data-loss controls at the point where information leaves can block a sensitive record on its way out.
And the highest-impact actions wait for a person to approve before they run. This is the same defense-in-depth approach Microsoft sets out in its own guidance, grounded in the Zero Trust principles it has held for years: least privilege and the assumption that a breach will get through, so the design has to contain the attempt rather than hope to block every one. Take just the data-loss layer.
In a Forrester study, organizations that fine-tuned their data-loss policies and gained real visibility into where their sensitive data lives cut the likelihood of a breach by about 30%, which comes from tuning the control rather than simply owning it.
On Microsoft Fabric, the misuse controls sit apart
On Microsoft Fabric, the division is clean. Fabric settles who is allowed in, through OneLake security, workspace roles, and the governance and admin controls layered around them, and that part is strong and mostly work you already do.
The controls that watch a permitted identity for misuse live in the Microsoft security stack around Fabric, in Sentinel, Purview, and Entra, and each is a separate service you turn on and tune to your environment. None of them activates because you stood up Fabric.
The point is that no single product is the control. Each is one part of something a person has to configure, tune to your data, and keep running as your agents change.
Your monitoring doesn’t know an agent’s normal
Turning the monitoring on is not the finish line either, because the monitoring you have was trained to recognize a person.
Behavioral detection works by learning what normal looks like and flagging what deviates from it. For a human account, the signals are familiar: a sign-in from a location the person has never used, or activity in the middle of the night when they are offline.
An agent produces none of those reliably. It has no home location, runs around the clock by design, and can legitimately read far more than its usual volume on a day when the workload spikes.
Point human-tuned detection at it, and you get one of two failures: real misuse that never trips an alert because it reads as ordinary machine activity, or a run of false alarms your team soon learns to ignore.
OWASP makes the same point in plainer terms, that when automated activity is indistinguishable from human activity, the audit trail stops telling you anything.
This is why detecting misuse has to be tuned to your data and to the agent’s real behavior before it means anything. A baseline built for people has to be rebuilt for the way an agent behaves, which is continuing work rather than a one-time switch.
Monitoring can be tuned to catch misuse, but keeping it tuned is a standing responsibility, and that responsibility only holds if someone owns it.
With no security lead, no one owns the misuse control
Beneath the technical gap is an ownership one, and it is the reason the misuse control so often stays off.
Turning it on and running it takes someone who owns the decision, and in a mid-size company that someone frequently does not exist. The people who feel the risk most keenly are rarely the ones who would configure the control.
Grant Thornton’s research shows the split plainly. More than half of operations leaders (54%) are concerned about the regulatory and compliance uncertainty posed by agentic AI, compared with just 20% of CIOs and CTOs.
The same research describes operations leaders finding governance gaps that finance is not funding and that technology is not surfacing.
Read the gap as an operating question, because that is what it is. The function that sees the exposure does not hold the console, and the function that holds the console does not carry the worry.
With no security lead to close the distance between them, the control that governs what a permitted agent does with your data becomes the layer everyone assumes belongs to someone else. It surfaces as unowned on the day an incident proves no one held it.
The control has to scale with every agent you add
None of this is a reason to slow down on agents. Putting them to work on your data is the return you modernized for, and that direction is the right one. What has to keep pace is the layer that governs what they do once they are working.
That layer will not hold still, because your estate will not. Every agent you add is another authorized user accessing the same consolidated data, so the surface area that needs governing grows in step with the value you are building.
So carry one question into your next review. Is anyone operating the control that decides what your agents do with everything they can now reach, and will that ownership still hold when you connect the next one?
Simform runs that layer when you do not have someone in-house to run it. As a Microsoft Azure Expert MSP and Fabric Featured Partner, we operate the identity, monitoring, and data-protection controls across your Azure and Fabric estate as part of daily operations, so putting AI to work on your data does not mean widening a gap no one is watching. Explore Simform’s Azure managed services.
