There is a particular kind of false confidence appearing in AI projects right now.
The pattern usually starts with a team getting an agent working in Microsoft Foundry, and because the demo is sharp and the outputs are mostly right, the conversation quickly shifts to what else it can do. A line about being helpful, harmless and secure goes into the prompt, the room is satisfied, and the project moves forward.
But a successful demo can disguise how little is known about the safety of the system around it.
Before deciding what an agent should do, teams need to understand what happens when it gets something wrong, what it has access to, what systems it can influence and whether the controls around it are proportionate to the consequences. Nothing in a successful demo answers those questions.
When an agent goes rogue, the cause is rarely malice and almost always poor scaffolding. Teams concentrate on prompting and overlook the enterprise-grade controls already built into Foundry because they’re treating it like a smarter chat interface when it’s really an enterprise platform with a serious blast radius if misused.
The most common design failure is also the most seductive: believing you can steer risk away through prompting alone. A prompt can shape behaviour, but it cannot substitute for guardrails, identity boundaries, network isolation, evaluations, red-team testing, audit and proper data access design. If those things are weak, the prompt is just decoration around a risky system.
If I could impart just one piece of advice, it would be to resist the temptation to build the shiny part first so you don’t end up with a helpful assistant that quietly becomes an unsafe enterprise interface.
When I look at an agent design, the first question I ask is what happens when it gets something wrong, rather than what it can do when everything goes right. Blast radius tells you what kind of system you’re being asked to review and determines what that review should examine.
Here’s a practical example of what I’ve seen in the wild. A team builds a narrow HR assistant designed to answer policy questions for new starters and people moving roles. It was connected to SharePoint Online to retrieve policy documents live, and the team had written clear do-and-do-not instructions into the prompt, including directions not to expose anything outside of policy material.
During testing, we discovered the service connection had broader access than anyone realised, including document libraries we beyond the intended policy content like payroll data.
The issue wasn’t the quality of the prompt, rather it was that the access model made the exposure possible. The team had spent time defining what the assistant should say, but not enough time constraining what it could reach. Access should follow purpose rather than convenience. Too many designs start with broad connectivity and then rely on the prompt to keep the agent in bounds.
As for the fix, it came down to scaffolding rather than prompt tuning. The service identity was narrowed, the source content was separated, the retrieval pattern was redesigned and stronger controls were added around what the assistant could access and return. When teams treat the prompt as the control, they miss where the real control surface sits.
The same applies to infrastructure agents, SQL-connected agents, internal knowledge assistants and workflow agents that can act on systems rather than just advise on them. The risk shape changes with the context. An agent that can read and write to SQL has a very different failure pattern from an agent that builds in Azure, which is why there is no universal catch-all risk rubric. Any rubric worth having is designed in the context of the agent it governs.
One of the strongest ideas in safer agent design is that risk evaluation should not live in just one place. If you only put risk logic in the prompt, it becomes fragile. If you only put it in the review process, it’s too late. If you only put it at tool execution, you miss broader context.
For a serious Foundry pattern, risk evaluation should exist across all three layers:
That layered approach helps prevent the kind of avoidable enterprise damage that occurs when an agent is allowed to act before anyone has considered the consequences. Auditability matters for the same reason. If you cannot reconstruct what the agent saw, did, called or returned, you don’t have meaningful control. It also creates a stronger review posture, because a bad review is basically hope. In enterprise environments, confidence comes from tested controls rather than successful demos.
Another common problem is trying to make one giant agent do everything. That usually looks clever at the start and messy later, because a huge system prompt with too many responsibilities becomes harder to reason about, harder to test, harder to secure and harder to review, and it also becomes less reusable.
In practice, skill boundaries should be driven by complexity and scope. If a task is reusable across multiple agents, that’s a strong case for making it a separate skill. If a task is bespoke and high-consequence, that’s a strong case for narrowing it into a tightly defined skill rather than hiding it inside a general-purpose agent.
The payoff is control as much as elegance. Narrower skills are easier to evaluate, easier to permission correctly and easier to review, and they make it far clearer where the risk sits.
A lot of agent risk starts upstream of the agent itself. If the source data is poorly governed, the agent will operationalise it rather than fix it.
One of the nastier patterns is when teams don’t properly understand the difference between pass-through security and acting through a service identity. In some cases, a service connection ends up being created with someone’s elevated personal access and the agent is suddenly operating with privileges far beyond what any ordinary user should have. That sounds dramatic, but it’s also entirely possible.
That’s why the right data access pattern is usually a combination of controls chosen deliberately for the data and the capability involved. Sometimes pass-through user context is the right answer, sometimes tightly scoped service identities are appropriate and other times retrieval boundaries need to do most of the containment work. It’s rarely one or the other.
If you’re using Foundry for serious enterprise work, the control surfaces shouldn’t stay at the level of slogans. Use the platform features that exist for this exact purpose like content filters and prompt shields to reduce unsafe or manipulated interactions, evaluation tooling to test behaviour systematically rather than anecdotally, AI red-teaming to pressure-test the system under hostile conditions and network isolation so the access path itself is not doing you damage.
Those features are the evidence that you are treating Foundry as an enterprise platform rather than a clever prompt wrapper. If a team claims an agent is safe but cannot show how those control surfaces have been applied, reviewed and tested, the confidence is running ahead of the engineering.
There is one question I think every Foundry team should be made to answer before release. It is uncomfortable in exactly the way a good review question should be: We know we can build this thing, but should we?
Asking yourself this question is responsible governance, because some agent ideas should be redesigned, constrained heavily or stopped entirely. An agent that reviewed Microsoft 365 productivity across the organisation, ranked employees by observed behaviour and referred low-ranked staff to HR for dismissal would raise ethical and organisational questions, and for me it is a hard no. Good review exists to test legitimacy, consequence and appropriateness, and a review that only ever rubber-stamps technical capability is not doing that job.
Foundry is a beast of a service, and I mean that as a warning against underestimating it rather than as a criticism. The risk is obvious: people see the shiny surface, assume they understand the platform and start building before they have established the scaffolding, which is backwards.
If you want agents that don’t go rogue, widen the thinking beyond the prompt. Start with intent, blast radius, access, auditability, human approval, governance, and the controls that define what an agent can see, do and influence. Then, before release, ask whether the thing should exist at all. That is what building with care looks like.
If you’re planning your first Foundry agents, or you already have some running and want confidence they are scaffolded properly, Data#3’s Azure specialists run a Foundry agent design review that works through exactly these questions.
To arrange one, speak with your Data#3 account manager or get in touch through the form below.
Information provided within this form will be handled in accordance with our privacy statement.