We have all seen the hacks in the news recently, and a lot of the coverage has focused on AI's role in them. It is something I was asked about a lot this week, so I thought I would put down some AI security tips.
Some of the biggest organisations are already reacting. At JPMorgan, Jamie Dimon described the simplest AI security control there is, restricting access. When asked about agentic AI, he told analysts the concern was heightened "because you don't want rogue agents, and there could be thousands of them", and that in the meantime "we're not going to allow just any outside agent to come inside the company because it's just too risky for clients."
He is not alone. A week later, Axios reported, citing people familiar with the issue, that Morgan Stanley is blocking 3rd party agents while JPMorgan, Bank of America and Citi are restricting them. These are outside agents logging into customers' accounts with the customer's own credentials, and the banks' problem is that many cannot tell whether that activity is actually what users have asked for. As a result, many are landing on read only access. Citigroup has said it on the record: no third-party agent logs in or transacts on its platforms, though customers can still grant limited, read only access through approved open banking providers. The agent can look, but it cannot move money.
In the same way that many of us struggle to control how businesses use and access our data, most of us cannot shut the door on agents like these banks. However, in my role and when building agents, I focus on how they can be used while ensuring they are safe. So I thought I would share some useful tips. Starting with which parts of this a platform can take off your hands, and which stay with you.
Three different problems wearing one name
AI security collapses three separate problems into one phrase, and most programmes stall because they try to solve all three with one control. It is worth separating them.
The first is what actions an agent can take. Something I cover in my talks is that what makes something an AI agent is that it can take actions, normally through interactions with other tools. An agent with tool access can send, delete, transfer and commit. The question stops being whether the output is accurate and becomes what it is permitted to touch, which is a point I have made here before and which has only got sharper since. The more the agent can do, the higher the risk.
The controls stack up as an agent does more
What the agent can do →
The second is the organisation leaking. The NCSC defines shadow AI as "the use of AI technology which isn't captured in an organisation's approved systems and processes", and in practice it is somebody pasting a customer file into an unchecked tool because the sanctioned tool is slower, or because this one has cool features. We have all heard it.
The third is the supply chain, and it is the one I would worry about most this year, because it is the one with the hardest numbers behind it.
Out of every 100 agent skills scanned, February 2026
37had at least one security flaw
13had at least one critical issue
2carried a confirmed malicious payload
Three problems, three different owners, three different controls. A platform can help with one of them, partially.
The one nobody can fix
Underneath all of it sits prompt injection, and the honest position on prompt injection is that it is not going to be solved. The clearest statement of that comes from the UK's national cyber authority. In December the NCSC wrote that "it's very possible that prompt injection attacks may never be totally mitigated in the way that SQL injection attacks can be", and followed it with advice I agree with: "Beware any that claim they can 'stop' prompt injection, and instead look at those who understand how they reduce it." I would put anyone who claims to stop it in the same category as anyone who says they know everything about AI.
Microsoft's own engineering documentation is blunter still. It states that “Prompt injection is the #1 risk on the OWASP LLM Top 10, and most agents in production today defend against it with one of two heuristics: a defensive system prompt, or a hand-rolled allow-list. Neither is deterministic.” Both can still fail.
It does however, go on to say that they have implemented an approach called FIDES, and it is the right shape of fix. Rather than trying to make the model resist the injection, it labels content as trusted or untrusted and checks those labels deterministically before every tool call. In Microsoft's words, "The model is still in charge of deciding what to do, but the framework is in charge of deciding what is allowed to happen." The model can still read the attack. It just cannot act on it. That contains the problem rather than removing it, and the page is open about the limits. FIDES is opt-in, Python-only for now and marked experimental, and it ships in the Agent Framework SDK rather than in Foundry Agent Service. Its protection is only as complete as your labelling of each data source, although anything left unlabelled is treated as untrusted by default. And once untrusted content enters a run, the rest of that run is treated as untrusted too, which is the point but also limits what the agent can do.
What I take from it is that the fix is not a better model. If the model cannot reliably separate an instruction from the data it's asked to read, then control cannot live inside the model. It has to live in what the agent can reach and do, which is an architecture decision, and therefore yours.
What the evidence will and will not support
Before buying anything, it is worth knowing how thin some of the numbers in this field are. I spent years in analytics watching a single percentage do lots of the arguing in a steering meeting, and this subject is full of them.
There are a number of reports that show a wide range of numbers for how many employees and businesses are using unapproved AI tools. However, in my experience most are either from companies that sell a tool, or are subjective at best. Additionally, for all the noise, one analysis counted a single GDPR fine ever issued in Europe against a generative AI provider: 15 million euros against OpenAI in November 2024, suspended in March 2025 and annulled by the Court of Rome in March 2026.
None of that means the risk is imaginary. The Snyk scan and the incident record are real. It means you should buy controls against your own threat model rather than against a statistic, because the statistic may not survive contact with anything in production.
Where a platform like Microsoft Foundry fits
Managed agent platforms are one option, and Microsoft Foundry is a useful one to look at because Microsoft documents the boundary clearly. Its shared responsibility model for AI agents puts Foundry Agent Service in the platform-as-a-service row: "Microsoft provides the runtime, model hosting, and platform safety controls. You own the agent's instructions, tool and plugin selection, tool permissions, orchestration logic, memory design, and the agent's identity and authorization."
In other words, the platform takes the runtime and some of the safety controls. The decisions that determine whether an incident happens stay with you.
Within that, it covers a lot of real areas. Model level guardrails, red teaming and tracing are generally available, and it also offers agent identity and network isolation. It is a massive help, but there is more you still need to do yourself, and two details show why.
The first is that some of the features are still in preview, including the agent guardrails (see Microsoft's guardrails documentation) and the two intervention points that inspect an agent's tool traffic, tool call and tool response. That is the channel an injected instruction arrives through, and I look forward to seeing how this will work when fully released.
The second is that layering can make things weaker. It is important to understand which guardrails apply where. Microsoft's documentation says "The agentic guardrail fully overrides the model's guardrail", so an agent with no tool-call controls can leave its tool traffic unscanned even when the model's guardrail would have caught it.
Microsoft's own rule of thumb is the right one to hold on to: "Autonomy never reduces accountability."
What actually keeps you safe
If detection cannot be relied on, containment has to carry the weight. Four things I would do to stay safe.
- Keep a registry of what each agent can do: not just a list of agents, but the actions each one can take, how it interacts with data, and what data it has access to. Include what you installed as well as what you built: skills, connectors, MCP servers and vendor AI features switched on by default. This is something I already implement across all my agents.
- Permission before capability: decide what an agent may reach before you decide what it may do. The banks' instinct to grant read-only access first is exactly this, applied to someone else's agent. Microsoft's own SDK documentation notes that by default every tool given to an agent is invoked without user approval, so approval is a thing you add rather than a thing you inherit.
- Know where the boundary is: it is not the prompt. The useful question is not what the agent was told, it is what it could send and where.
- A human on anything irreversible: and accept that this is a gate rather than just a policy. When the UK's AI Security Institute published an incident report on its own cyber testing in August, its agents had taken 19 unsanctioned actions across 10 of 122 runs, and its assessment was that "the margin between failure and success was narrow, resting on human vigilance". Its conclusion is the one to take: "good containment should not depend on the model choosing not to test its boundaries."
The registry is the one I would start with, and it is something I have worked on directly, a record of every agent, the actions it can take, how it interacts with data, and what data it can reach. The other controls depend on it. You cannot scope permissions, watch the boundary or put a human on the irreversible actions for an agent you do not know is there. Platforms are starting to offer this too, Foundry's control plane among them, though its guardrails only apply to agents built in Foundry. A registry is only as useful as the controls it is connected to.
Where I would start
Three things, and none of them need a purchase order.
- Start the registry: every agent, what it can do, how it uses data and what it can reach, including the ones you installed rather than built. If nobody can fill it in, that is the finding.
- Go through each agent and name the irreversible actions it can take, then check whether a human approves them today or whether that was assumed.
- Write down which parts of the job your platform does and which are yours, and be honest about the second list.
I think the platforms will close some of this, as more and more features become available. What will not change is the shape of the responsibility model, because no vendor can own the question of what your agent is allowed to do on your behalf. That one is always going to stay with the business and the builders. This sits alongside the data questions I wrote about in securing AI at the edge, which is the other half of the same job.
Feel free to reach out if you'd like to know more or have any questions.