ChatGPT
Perplexity
In Copilot Studio, an analyst can build an agent, connect it to company data, and share it with colleagues without involving engineering. Oversight hasn’t kept pace with that freedom, and in Gartner’s April 2026 release on agent sprawl, only 13% of organizations believe they have the right AI agent governance.
Before changing any settings, list the agents your teams have built and check each one against four questions.
- Who can reach the agent?
- Whose access does it use?
- Can it send data or take action outside the company?
- Who owns it today?
The four gaps below follow these questions in order, and the first agents to fix are the ones where these risks combine, such as an agent open to the whole company that runs on its builder’s access and can send data outside.
1. Agents shared with the whole company or published without sign-in
Sharing an agent with the whole company is the quickest way to let colleagues try it, and some agents are published with sign-in switched off, either because it was disabled for testing or because the builder assumed it was optional.
Either way, people with no reason to use the agent can access it, and if the agent’s access is broader than their own, they can see or do more than their role allows.
What the research found
Microsoft’s Defender research team lists agents shared with the entire organization and agents that require no sign-in as the first two of ten misconfigurations it observes in real environments.
How to fix
Copilot Studio sets new agents to require Microsoft sign-in and warns builders who change that before publishing, but those defaults do not reach agents already live.
Check agents already live for both settings, and use admin controls to cap how many people an agent can be shared with and to block agents that run without sign-in.
Company-wide sharing is still reasonable for an agent that only reads information and runs on each user’s own access, because every person then sees only what they could already open. An agent without sign-in makes sense only when it answers from public content, such as a website FAQ.
Stay updated with Simform’s weekly insights.
2. Agents that run on their builder’s or their own stored credentials
When a builder connects an agent’s tools with their own account, the agent uses that account for everyone who talks to it.
A colleague can then ask it a question and have it open files or trigger actions only the builder can, as Microsoft’s documentation on maker credentials warns.
Agents that run in the background need their own credential, such as the token issued when an app is connected, and that credential needs the same care, because anyone who steals it gets the agent’s access.
Case in point
In August 2025, attackers stole the OAuth tokens that connected Drift, Salesloft’s AI chat agent, to customers’ Salesforce and Google Workspace accounts.
According to FINRA, they used those tokens to impersonate the trusted Drift app, bypass multi-factor authentication, and export data from more than 700 organizations, including contact records and, in some cases, API keys and passwords stored in support cases.
How to fix it
Keep shared agents on each user’s own credentials, and in the environments where agents are shared, turn on the admin control that blocks builder credentials, since Copilot Studio allows them by default.
When we built five agent workflows on Azure AI Foundry for a US HVAC group with 23 subsidiaries, every user signed in through Microsoft single sign-on and worked within role-based permissions, and supervisors approved records from a single dashboard.
The control applies to every agent in the environment, and agents that run on a schedule or in the background stop working under it, because each call then needs a signed-in user. Follow the order in Gap 4 before you turn it on.
Keep those background agents in a separate environment where the control stays off, and connect their tools through a company-owned account with only the access the task needs, never through an employee’s own login.
Store any secrets, such as keys and tokens, in Azure Key Vault. Connect only the apps and MCP tools IT has approved, because Microsoft’s research finds MCP tools switched on by default and copied between agents.
3. Agents that read outside content and can send data out
An agent reads whatever text it is given, and it can mistake instructions written into that text for instructions from its user.
Someone outside the company can exploit this by planting a command in a web form or an email, such as an instruction to send the customer list to a particular address.
If the agent can also email any address or call outside websites, it may carry out that command and send your data to the attacker.
Case in point
In September 2025, researchers hid instructions in a public web-to-lead form, and Salesforce’s Agentforce read and acted on them. The data went out through a domain that had expired but was still on Salesforce’s trusted list, and the researchers had bought it for $5.
As The Register reported, Salesforce began enforcing trusted-URL lists for its agents and said it had released patches that stop agent output from being sent to untrusted URLs. It declined to say whether the flaw was abused.
How to fix it
Limit whom an agent can email, keep its list of allowed web destinations current, and turn off actions it doesn’t need. If an agent can send to an external address, have a person approve each message before it goes out.
That step is unnecessary for an assistant that only drafts messages for a person to send, or for an automated flow that always emails the same internal list, because neither one decides where a message goes, so a planted command has nowhere to send your data.
Where approval stays in place, check that reviewers still read what they approve, because the check weakens as the agent gets more reliable.
For an HR agent that answers company-wide policy questions and emails candidates, I would limit sharing to HR and require approval for candidate emails.
4. Agents still running after their builder has left
Microsoft’s research notes that an unused published agent can still be called, and one whose owner has left keeps its connections with nobody accountable.
Case in point
The clearest recent example is a forgotten account on an AI hiring platform.
In June 2025, researchers got into the back end of McHire, the hiring chatbot Paradox.ai runs for McDonald’s, through a test account nobody had logged into since 2019.
They reported its username and password were both 123456, and Paradox’s disclosure says the password was never updated and the account should have been decommissioned.
A second flaw, in an API, led the researchers to estimate that more than 64 million records were reachable, as SC Media reported.
Paradox says the researchers pulled seven records, five with candidate contact details, and that it fixed both flaws within hours. Both flaws sat in the platform’s admin login and an API behind the chatbot.
How to fix it
Consider a finance agent still running month-end reconciliation on a departed builder’s access. Blocking builder credentials in its environment would stop the reconciliation, since nobody is signed in when it runs.
Assign a finance owner, move the agent into the environment set aside for background agents, and move its connections off the departed builder’s login to a company-owned account.
Once it runs there, enforce the block in the environments where your shared agents live. If nobody can take ownership before the next run, quarantine the agent. If it was personal to its builder and nobody else relies on it, retire it.
Keep each agent owned, and keep the approved route easy
An agent is ready to run unattended only when all four questions have clear answers, and the fourth decides whether the other three stay answered.
The owner should review the agent whenever it gains a new tool or connection or goes 30 days without use.
Tight controls carry their own risk. Gartner warns in the same release that employees who cannot get their work done in approved tools turn to unapproved AI.
Microsoft’s Cyber Pulse report, drawing on its survey of data security leaders, puts the share of employees already using unapproved agents at 29%.
The approved way of building agents has to stay the easier one. Simform’s agentic AI team works with business teams to set up the identities, permissions, and owners that keep it that way.
