Microsoft 365 Copilot Agents: A UK Business Guide to Building Custom Copilot Agents Without a Development Team in 2026

Copilot Studio and the lighter agent-building tools inside Microsoft 365 Copilot change what Copilot is for a business. Out of the box, Copilot is a general assistant: it answers questions, drafts documents and summarises meetings using whatever the signed-in user can access. A custom agent is something narrower and more deliberate — an assistant configured for one job, given specific instructions, pointed at specific knowledge, and optionally allowed to take specific actions. Most UK businesses paying for Copilot have never built one, and the gap between a general assistant everyone tries and a focused agent that a team uses every day is frequently where the return on the licence actually sits.

This guide is for organisations that want to build agents without a development team, and that want to know where the sensible limits are. It explains what a custom agent actually consists of and how it differs from default Copilot, the realistic no-code and low-code scenarios that work well, which data sources an agent can safely be grounded in and which create risk, the authentication decision that most often turns a helpful agent into a data exposure, the governance and publishing controls that keep agent sprawl manageable, and where a custom agent stops being a sensible do-it-yourself project and needs proper engineering. Microsoft’s naming and packaging in this area change frequently, so the guide describes capabilities rather than relying on product names that may have moved by the time you read it.

What a custom Copilot agent actually is

Strip away the terminology and a custom agent has three parts, of which only the first is mandatory.

Instructions. A description of the agent’s purpose, tone, boundaries and behaviour: answer questions about our HR policies, cite the policy document, refuse questions about individual employees, suggest contacting HR for anything not covered. Instructions are what make an agent focused rather than general, and good ones are specific about what the agent should decline as well as what it should do.

Knowledge. The sources the agent grounds its answers in — particular SharePoint sites or document libraries, specific files, approved public web pages, or data from other business systems brought in through connectors. Restricting knowledge to a curated set is what makes an agent’s answers more reliable than a general assistant searching everything a user can see.

Actions. Optionally, the ability to do something rather than only answer: create a ticket, look up an order, submit a form, update a record, trigger a workflow. Actions are where agents become genuinely useful for operational work, and also where the risk changes character, because an agent that can write is a different proposition from one that can only read.

Two levels of building

Microsoft provides building at two levels. A lightweight builder within the Microsoft 365 Copilot experience lets users create agents by describing what they want in plain language and selecting knowledge sources, with no technical skill. These are often described as declarative agents: they extend Copilot with instructions and knowledge and run on Copilot’s own orchestration. The full Copilot Studio adds structured conversation topics, actions through connectors and workflows, more control over behaviour, multiple publishing channels, and integration with the wider Power Platform. The first suits personal and team helpers; the second suits agents that a department relies on or that take actions in other systems.

How this differs from default Copilot

Default Copilot is broad and personal: it searches everything you can access and helps with whatever you ask. A custom agent is narrow and shared: it applies the same instructions and the same curated knowledge for everyone who uses it, which makes its behaviour predictable and its answers consistent. That consistency is the point. A new starter asking the onboarding agent about expenses gets the same answer, from the same policy, as everyone else — rather than whatever general Copilot assembles from whichever documents that person happens to have access to.

Where custom agents actually succeed

The chart below shows which first agents are still in active use six months after launch, across UK organisations we have supported. The pattern is clear: narrow, read-only agents grounded in maintained content survive; ambitious general-purpose ones are quietly abandoned.

The bottom row is the instructive one. An agent grounded in “everything” behaves much like default Copilot with extra steps, inherits every gap and contradiction in the underlying content, and gives answers that are hard to trust because nobody knows which document they came from. Users try it, get an inconsistent answer, and go back to asking a colleague. Survival rates fall as scope widens.

The action row sits in the middle for a different reason. Agents that take actions can be extremely valuable and they need more care: a defined set of permitted actions, authentication handled correctly, testing against realistic inputs, and an owner. Many that fail were built as quickly as a read-only agent and treated with the same informality, which is the wrong approach for something that writes to a system of record.

The top rows share three properties: a bounded question set, an authoritative source document that somebody already maintains, and a recognisable pattern of repeated interruptions the agent replaces. When all three are present, an agent built in an afternoon can remain useful for years, provided the underlying content is kept current.

Custom agents in UK businesses — the numbers

The figures below reflect what we observe across UK organisations of 50 to 500 staff that have deployed Microsoft 365 Copilot and begun building agents.

The first two figures together describe the opportunity. Most organisations paying for Copilot have never extended it, and a useful agent for a bounded task takes an afternoon. That combination is why custom agents are one of the more reliable ways to improve the utilisation and evidenced value of Copilot licences — a point that connects to measuring return, covered in our guide to measuring Microsoft 365 Copilot ROI.

The last two figures describe the risk, and both are configuration rather than technology. Where any user can publish an agent to the whole organisation, sprawl and inconsistent answers follow quickly. Where an action-taking agent authenticates as the person who built it, everyone who uses the agent effectively borrows that person’s access to the connected system — which is the single most consequential mistake in agent building and is explained in detail below.

Where custom agents create risk

The grid below groups the risk areas in custom agent building. Badges reflect how often each causes a real problem — data exposure, wrong answers acted on, or unmanageable sprawl — in organisations building without specialist support.

The first row of the first card is the issue that most often surprises people, and it is inherited rather than created. Agents grounded in Microsoft 365 content respect each user’s existing permissions, so an agent will only surface what the person asking could already open. That sounds reassuring, and it means an agent is exactly as safe as your permissions are. If a sensitive HR folder is shared with everyone through a forgotten link, an agent pointed at that site will happily summarise it for anyone who asks. Agents do not create oversharing; they make it findable. Fixing permissions before pointing agents at content is the same prerequisite discussed in our guide to Microsoft 365 Copilot data security.

The governance card’s first row is the one most tenants have not configured. By default in many tenants, a user who builds an agent can share it widely. That is excellent for experimentation and poor for an organisation that wants consistent answers, because within months there are several agents claiming to answer HR questions, built by different people from different sources, and nobody knows which to trust.

Default Copilot against a custom agent

The comparison below highlights the custom agent. The qualification is that agents only earn their keep for repeated, bounded tasks with an authoritative source. For one-off questions and personal productivity, default Copilot is the right tool and building an agent adds nothing.

The consistency row is why agents matter in a business context. Default Copilot’s answers depend on what each user can see, so two people asking the same question may get different answers drawn from different documents. An agent grounded in the current policy library gives everyone the same answer from the same source, with a citation, which is the property that makes an assistant suitable for anything resembling official guidance.

The governance row is the honest cost. An agent shared across a team is a small piece of business infrastructure: it needs an owner, its knowledge sources need maintaining, and changes need checking before they reach users. That overhead is modest for read-only agents and grows with every action an agent can take.

Choosing the right building tool

The two levels of building tool suit different jobs. The table below summarises the practical differences; exact features and names evolve, so treat it as a guide to which level of tool a scenario needs rather than a definitive specification.

The practical rule is to start in the lightweight builder for any read-only agent that answers questions from documents, and move to full Copilot Studio when an agent needs to take actions, follow structured conversations, reach users outside Microsoft 365, or be managed with proper environments and change control. Starting simple and graduating is considerably safer than starting in the full tool and building actions before the read-only version has proven useful.

Three realistic build scenarios

The scenarios below illustrate what no-code and low-code agent building looks like in practice for a UK SME, from the simplest to the point where technical support becomes worthwhile.

Scenario one: an HR policy agent

A people team receives the same questions every week about annual leave, sickness reporting, expenses, parental leave and hybrid working. The policies already exist in a SharePoint library the team maintains. A team member builds a read-only agent in the lightweight builder, points it only at that library, and writes instructions: answer from the policies, cite the document and section, never discuss individual employees or cases, and direct anything not covered to the HR inbox. After testing against forty genuine questions collected from the inbox, two policies turn out to contradict each other on carry-over, and the fix is to the documents, not the agent. Build time is an afternoon; content correction takes a week. The agent is published to all staff through the approval route with the head of HR as owner.

Scenario two: an IT help agent that raises tickets

An internal IT team wants an agent that answers common how-to questions from its knowledge base and, where it cannot help, creates a ticket on the user’s behalf with a summary of the problem. The question-answering part is straightforward. The ticket creation is an action into the service desk system through a connector, which moves the build into Copilot Studio and raises the design questions: the connector should authenticate as the user so tickets are raised in their name and they cannot see others’ tickets; the agent should confirm the summary with the user before submitting; and duplicate tickets from repeated attempts should be prevented. A capable IT administrator can build this with some care, and it benefits from a short review of the authentication and a test as an ordinary user before release.

Scenario three: a sales assistant drawing on CRM and pricing

A sales team wants an agent that can find the right case study and product sheet for a prospect, look up the customer’s history in the CRM, and draft a proposal using current pricing. This spans curated SharePoint content, a CRM connector reading customer data, and a pricing source that must be authoritative. It is achievable in Copilot Studio, and it is the kind of agent where technical support earns its cost: CRM access must respect each salesperson’s permissions, pricing must come from a single maintained source rather than old proposals, drafted documents should be reviewed before sending, and changes should be tested before they reach the team. Built well, it saves real time; built quickly with the maker’s credentials and grounded in a folder of old proposals, it quotes superseded prices and exposes customer data across the team.

The progression across the three is the point. The first is a content exercise with a little configuration. The second introduces a single action and the authentication question. The third combines several sources and systems, at which point design, testing and ownership matter more than the building itself. Most organisations should build several of the first kind, a few of the second, and approach the third with support.

Building a first agent in six weeks

The sequence below takes an organisation from no custom agents to one well-governed agent in daily use, and leaves the foundations in place for the next. It is deliberately conservative: read-only first, governance before wide release.

Weeks two and three do most of the work, and neither involves the agent itself. Cleaning the source content and testing with real questions are what separate an agent people trust from one they abandon. Organisations that build in an afternoon and publish the same day typically discover inconsistent answers within a week, at which point users have formed an opinion that is hard to reverse.

The publishing controls in week one are the governance decision with the longest consequences. Setting them before the first agent exists costs a short conversation; setting them after thirty agents have appeared means deciding which to keep, who owns them, and how to tell users which one to trust.

What custom agents cost

Agent costs have two parts: Microsoft licensing and consumption, and the effort to build and maintain. Microsoft’s licensing for agents has changed several times and continues to evolve, with a mix of per-user licences and metered consumption depending on who uses an agent and what it does. The table below shows the structure with indicative figures; confirm the current position with your licensing partner before budgeting.

The metered row is the one to watch. Where agents are used by people without a full Copilot licence, take actions, or are published to channels outside Microsoft 365, usage may be charged by consumption rather than covered by a licence. That is a sensible model for occasional use and can grow without anyone noticing when a popular agent is shared widely. Set consumption budgets and review usage monthly, in the same way you would for any metered cloud service.

The build rows reflect where the effort actually goes. For read-only agents, most of the cost is content preparation and testing rather than configuring the agent, which is why organisations with well-maintained document libraries can build useful agents very cheaply. For action-taking agents, authentication design, testing and environment management dominate. The wider licence economics are covered in our guide to Microsoft 365 Copilot cost.

The setting that decides how far agents spread

If one configuration decision determines whether custom agents become a well-governed asset or an unmanageable sprawl, it is who is allowed to share an agent across the whole organisation.

Fifty-eight per cent means that in most tenants, the first enthusiastic user to build an HR agent can make it available to everyone, grounded in whatever sources they chose, with no review of whether its answers are right. Multiply that across departments and the result within a year is several overlapping agents giving inconsistent answers, some built from outdated content, many with no owner once their maker moves on.

The remedy is not to prevent building. Personal and team-level experimentation should be easy, because that is how useful ideas emerge. The control belongs at the point of organisation-wide publishing: a lightweight approval step, a recorded owner, and a check that the knowledge sources are authoritative and the permissions are sound. Microsoft provides controls for this in the admin centres, and configuring them takes far less time than untangling agent sprawl later.

The same principle applies with more force to agents published outside the organisation. An agent available to customers or the public represents your business in every answer it gives, and should never reach that audience without deliberate review, testing and ongoing ownership.

The authentication decision that matters most

When an agent takes an action in another system — reading a CRM record, creating a ticket, querying a database — it has to authenticate to that system somehow. There are broadly two ways, and choosing the wrong one is the most consequential mistake in agent building.

The agent acts as the user

Each person using the agent signs in, and the agent acts with that person’s own permissions in the connected system. A user who cannot see a particular customer record in the CRM cannot see it through the agent either. This preserves your existing access controls and is the right default for almost every internal agent that touches business data.

The agent acts as the maker, or a fixed account

The agent uses one set of credentials — often those of the person who built it, because that is what the builder was signed in with — for every user. Everyone who uses the agent then effectively borrows that identity’s access. If the maker was a finance manager with access to payroll, any member of staff using the agent may be able to retrieve payroll data through it, regardless of their own permissions.

This is not a theoretical concern. It arises naturally because building an agent while signed in as yourself, and testing it as yourself, works perfectly; the problem only appears when someone else uses it. In roughly a third of action-taking agents we review, actions run with the maker’s own credentials, and in most of those cases the maker had not realised.

When a fixed identity is appropriate

There are legitimate uses for a fixed identity: an agent that retrieves only public product information, or submits a form into a queue that everyone is allowed to submit to. In those cases, use a dedicated service identity with the narrowest possible permissions — never a person’s own account — so that the agent can only do the specific thing it exists to do. The principles are the same as for any non-human identity, set out in our guide to Azure identity and access management.

The practical test before publishing any agent with actions: sign in as an ordinary user with deliberately limited access, use the agent, and confirm it cannot do or see anything that user could not do or see directly.

Which data sources an agent can safely use

Not every source is equally suitable for grounding an agent. The distinctions below reflect both answer quality and exposure risk.

Curated SharePoint libraries with an owner. The best source for most agents: a defined set of authoritative documents, permissions checked, someone responsible for keeping them current. Answers are citable and consistent.

Broad SharePoint sites or whole tenants. Workable only where permissions are genuinely sound, and generally poor for answer quality because broad sources contain drafts, superseded versions and contradictions. If you would not hand a new starter the whole site and tell them it is the official guidance, do not hand it to an agent.

Uploaded files. Convenient and easy to forget. A file uploaded directly to an agent becomes a private copy that does not update when the original changes, so the agent goes on citing last year’s policy indefinitely. Prefer pointing at a maintained library.

Public websites. Useful for agents that need to reference your own public content or a specific authoritative external source. Restrict to named sites rather than open web search where accuracy matters, because content you do not control can change or be wrong.

Business systems through connectors. Powerful and the area needing most care: check what data the connector exposes, ensure authentication acts as the user, and apply data loss prevention policies that govern which connectors can be combined.

Content to keep out. Highly sensitive material — HR casework, legal matters, board papers, personal data beyond what the agent’s purpose requires — should be excluded from grounding even where permissions would technically allow a user to see it. Sensitivity labels and site-level restrictions help enforce this. The agent’s purpose should determine its sources, not the other way round.

Benchmarks — agent practice against what we find

The figures below show how often each practice is in place across UK organisations that have begun building custom Copilot agents.

Eighty-four per cent have someone building agents and seventeen per cent know what agents exist. That gap is how sprawl starts: building is easy and encouraged, while inventory and ownership are nobody’s job. A simple register — agent name, owner, purpose, sources, audience — maintained alongside the publishing approval is enough for most organisations.

The testing figure at twenty-one per cent connects to a wider point about AI systems: an agent that answers fluently is not necessarily answering correctly, and the only way to know is to check its answers against the source on realistic questions. The disciplines involved are covered in our guide to AI agent reliability testing, and apply in scaled-down form even to simple read-only agents.

Agent readiness — where most UK organisations sit

Combining the assessment areas gives an indication of how ready an organisation is to build and run custom agents safely at scale. The gauge reflects a first review of a UK organisation with Microsoft 365 Copilot deployed and some agent experimentation under way.

A score in the low thirties reflects enthusiasm ahead of structure. Building capability scores well, because the tools are accessible and people try them. Content readiness scores moderately to poorly, depending on how well document libraries are maintained. Permissions score poorly in most tenants, for the same oversharing reasons that affect Copilot generally. Governance — publishing control, ownership, inventory, consumption budgets — scores lowest because it is rarely set up before the first agents appear.

The useful feature here is that the governance gap is quick to close and the content gap is valuable to close for reasons beyond agents. Publishing controls and an agent register take a day. Cleaning and owning the document libraries that agents rely on improves Copilot’s general answers, search, and every human who looks for the same documents.

Where DIY stops and engineering starts

No-code agent building is genuinely capable, and there is a point at which it stops being the right approach. Recognising that point early avoids an agent that works in a demonstration and fails in production.

When the agent writes to systems of record. Creating invoices, changing customer records, approving requests or moving money require careful authentication design, confirmation steps, error handling, idempotency so retries do not duplicate actions, and audit trails. These can be built in Copilot Studio, and they benefit from someone who designs and tests them deliberately rather than by trial and error.

When it spans several systems. An agent that reads from the CRM, checks stock in the ERP and creates a ticket in the service desk is coordinating three integrations with three failure modes. The complexity grows faster than the number of systems.

When external users depend on it. Customer-facing agents represent the business in every answer, need protection against misuse and manipulation by people trying to make them say or do things they should not, and must handle volume. They warrant proper testing, monitoring and ownership.

When it informs consequential decisions. Agents whose output feeds decisions about people — recruitment, credit, eligibility — raise data protection and fairness obligations that go beyond agent configuration, and should not be built as an informal project.

When it needs proper change control. Once an agent matters, changes should be developed and tested away from the version people use, then promoted deliberately. That requires environments and a release process, which is engineering practice rather than no-code building.

When the built-in orchestration is not enough. Some requirements need custom logic, specific models, or integration patterns beyond what the no-code tools provide. At that point a custom-built agent, sometimes still surfaced inside Microsoft 365, is the appropriate route.

The sensible pattern for most organisations is a split: business teams build and own read-only agents grounded in their own content, within published guardrails, while action-taking, multi-system and external agents are built with technical support and run with engineering discipline. That gives the speed of no-code where it is safe and the rigour of engineering where it matters.

Common mistakes with custom Copilot agents

The errors below recur across UK organisations building agents. Most stem from treating agent building as a feature to try rather than a small piece of shared infrastructure.

• Building a general “ask anything” agent first. Broad scope produces inconsistent answers and low trust. Start narrow with one bounded task and an authoritative source.
• Grounding agents in overshared content. Agents respect user permissions, so they make existing oversharing findable. Review permissions before pointing an agent at a site.
• Letting actions run with the maker’s credentials. Everyone who uses the agent borrows the maker’s access. Default to user authentication; where a fixed identity is needed, use a narrowly scoped service identity.
• Uploading files instead of linking maintained sources. Uploaded files become stale private copies, and the agent keeps citing outdated policy.
• Publishing without testing. Fluent answers are not necessarily correct. Test against thirty to fifty real questions and check each against the source.
• Leaving organisation-wide publishing open to everyone. Overlapping agents with different answers appear quickly. Approve organisation-wide publication and record an owner.
• No owner for content or agent. Agents decay as their sources drift. Someone must keep both the agent and its knowledge current.
• Ignoring metered consumption. Widely shared agents used by unlicensed users or taking actions can incur charges that grow quietly. Set budgets and review monthly.
• Adding write actions before the read-only version has proven useful. Prove value safely first, then extend.
• Publishing externally without review. A customer-facing agent represents the business in every answer and attracts deliberate misuse. Treat it as a production system.

What this looks like in practice

A UK property management company with 160 staff had deployed Microsoft 365 Copilot to around eighty users and was struggling to show value; usage had settled at a fraction of the licences. The IT manager decided to try custom agents, and within a month staff across the business had built eleven, several published organisation-wide.

A review found the typical pattern. Three separate agents claimed to answer HR questions, each grounded in a different combination of folders, one of which included an old site containing superseded policies; they gave different answers about annual leave carry-over. An agent built by the finance team to look up tenant arrears used a connector to the property management system authenticated with the finance manager’s own account, so any member of staff could retrieve arrears data for any tenant. And an agent grounded in “the whole intranet” had surfaced a disciplinary investigation document, because the folder containing it had been shared with everyone by mistake two years earlier.

None of this was malicious, and all of it followed from defaults. Anyone could build and publish, nobody tested against real questions, and nobody had considered which credentials the arrears agent used.

The remediation took five weeks. Organisation-wide publishing was restricted to approved agents with named owners, and the eleven agents were consolidated to four. The three HR agents were replaced by one grounded only in a cleaned, owned policy library, tested against forty questions the HR team actually received. The arrears agent was rebuilt to authenticate as each user, so staff saw only the tenancies they managed. The intranet-wide agent was retired, and the permission review it prompted closed the overshared folder along with several others. Consumption budgets were set for the two agents used by unlicensed staff.

The agents were the easy part — people built them in an afternoon and loved them. What we had not thought about was that the arrears agent was effectively handing out the finance manager’s access to everyone, and that the intranet one had found a document nobody should have been able to see. The consolidated set is smaller, and people trust it, which is why it actually gets used.

Two points generalise. The first is that agent problems are almost always configuration and content problems: permissions, credentials and source quality determined every issue found. The second is that consolidation improved adoption. Fewer, trusted agents with consistent answers saw more use than eleven overlapping ones, and Copilot utilisation across the licensed group rose as a result.

The 12-point custom agent checklist

Items one to four set foundations before building. Items five to nine cover building and releasing. Items ten to twelve keep agents healthy.

1. Set publishing controls before the first agent. Who may build, who may share beyond themselves, and approval for organisation-wide publication.
2. Start with one bounded, read-only use case. Repeated questions, an authoritative source, a team that will use it.
3. Name an owner for the agent and for its content. Agents decay when their sources drift; someone must keep both current.
4. Review permissions on the knowledge source. Agents make existing oversharing findable. Fix it before grounding.
5. Ground in curated, maintained libraries rather than uploads or whole sites. Consistency and citability depend on it.
6. Write specific instructions, including what to refuse. Purpose, tone, citation requirements and redirection for out-of-scope questions.
7. Test against thirty to fifty real questions before release. Check every answer against the source and fix content gaps.
8. Pilot with the team it serves before widening. Most problems surface in the first fortnight and are content problems.
9. For action agents, authenticate as the user. Where a fixed identity is genuinely needed, use a narrowly scoped service identity, never a person’s own account. Test as a low-privilege user.
10. Maintain an agent register. Name, owner, purpose, sources, audience, authentication method. Review quarterly and retire duplicates.
11. Set consumption budgets for metered usage. And review usage monthly alongside other cloud spend.
12. Escalate to engineering at the right point. Writes to systems of record, multiple integrations, external users and consequential decisions warrant technical design and change control.

At a glance — custom Copilot agents

How Cloudswitched approaches Copilot agents

Cloudswitched helps UK organisations extend Microsoft 365 Copilot with custom agents, and we start with the foundations rather than the build. In practice that means configuring publishing controls and an agent register before the first agent goes wide, reviewing permissions on the content agents will draw from, helping teams choose bounded use cases with authoritative sources, testing agents against the questions people actually ask, and designing authentication for action-taking agents so that nobody borrows anyone else’s access. Where an agent needs to write to business systems, span several integrations or face customers, we build it with proper testing and change control. Where a team can safely own a read-only agent themselves, we set up the guardrails and step back.

Frequently Asked Questions

What is a custom Copilot agent?

A version of Copilot configured for a specific job. It has instructions describing its purpose, tone and boundaries; knowledge sources it grounds its answers in, such as particular SharePoint libraries or approved websites; and optionally actions it can take in other systems through connectors and workflows. Unlike default Copilot, which searches everything a user can access and responds to whatever they type, a custom agent applies the same instructions and curated sources for everyone who uses it, which makes its answers more consistent and easier to trust for business guidance.

Can we build Copilot agents without developers?

Yes, for a large class of useful agents. Read-only agents that answer questions from curated documents can be built by non-technical staff in a few hours using the lightweight builder in Microsoft 365 Copilot, and most of the effort goes into preparing the content and testing the answers rather than configuring the agent. Agents that take actions in business systems, span multiple integrations, serve external users or inform consequential decisions benefit from technical design, testing and change control, and are better built with that support.

What is the difference between the agent builder in Copilot and Copilot Studio?

The lightweight builder within Microsoft 365 Copilot lets users create agents by describing their purpose and selecting knowledge sources, and suits read-only question-answering agents for individuals and teams. Copilot Studio is the fuller tool, adding structured conversation topics, actions through connectors and automated flows, publishing to channels beyond Microsoft 365, and management through separate environments. A sensible pattern is to start in the lightweight builder and move to Copilot Studio when an agent needs actions, structured flows or proper change control. Microsoft’s naming in this area changes regularly.

Are custom agents secure?

They can be, and their security depends mostly on configuration you control. For Microsoft 365 content, agents respect each user’s existing permissions, which means they are only as safe as your permissions: overshared folders become findable through an agent. For action-taking agents, the authentication method is critical — agents should normally act as the signed-in user, not with the maker’s credentials. Publishing controls, data loss prevention policies on connectors and testing as a low-privilege user before release address most remaining risk. Our guide to Copilot readiness covers the tenant preparation involved.

What data can a Copilot agent access?

Whatever knowledge sources you configure, subject to the user’s permissions for Microsoft 365 content: SharePoint sites and libraries, specific files, approved public websites, and data from other systems brought in through connectors. The safest sources are curated, owned document libraries with checked permissions. Uploaded files are convenient but become stale private copies. Broad sources such as whole sites reduce answer quality and widen exposure. Highly sensitive content should be excluded from grounding even where a user could technically open it.

Why do custom agents give inconsistent answers?

Almost always because of their knowledge sources. Agents grounded in broad sites inherit drafts, superseded versions and contradictory documents, and may draw on different ones for similar questions. Several overlapping agents built by different people from different sources compound the problem. The fixes are narrowing each agent to a curated, maintained library, resolving contradictions in the content, consolidating duplicate agents, and testing against real questions before release. Inconsistency is usually a content problem rather than an agent problem.

What is the risk of an agent using the maker’s credentials?

Everyone who uses the agent effectively borrows the maker’s access to the connected system. If an agent that queries a finance or HR system was built by someone with broad access, and its connection uses their account, any user of the agent may be able to retrieve data they could not see directly. This happens naturally because building and testing as yourself works perfectly. Default to user authentication for any agent touching business data, and where a fixed identity is genuinely appropriate, use a dedicated service identity with the narrowest possible permissions.

How do we stop agent sprawl?

Control the point of organisation-wide publishing rather than the act of building. Let people experiment with personal and team agents, but require approval and a named owner before an agent is shared across the organisation, and maintain a simple register of published agents recording purpose, sources, audience and authentication. Review the register quarterly, consolidate overlapping agents and retire those whose owners have left. In most tenants, these controls are available in the admin centres and take far less time to configure than untangling sprawl later.

How much do custom Copilot agents cost?

Licensing depends on who uses an agent and what it does. Users with a Microsoft 365 Copilot licence are generally covered for agents grounded in their work data, while usage by unlicensed users, some actions and external channels may be metered by consumption. Premium connectors to other systems may need additional Power Platform licensing. Build effort is typically modest for read-only agents — often a few hundred to a couple of thousand pounds with partner support — and higher for action-taking agents. Microsoft’s agent licensing changes regularly, so confirm current terms before budgeting.

Can Copilot agents take actions in other systems?

Yes, through connectors and automated workflows, particularly when built in Copilot Studio. Agents can look up records, create tickets, submit forms and update systems. Actions are where agents become operationally valuable and where risk rises, so they need defined permitted actions, user-based authentication, confirmation steps before writes, testing against realistic inputs including unusual ones, and an owner. Prove a read-only version first, then add actions deliberately rather than building them in from the start.

Should we publish a Copilot agent to customers?

Only with deliberate review, testing and ongoing ownership. A customer-facing agent represents your business in every answer, will receive questions you did not anticipate, and will attract attempts to make it say or do things it should not. It needs restricted knowledge sources, careful instructions, testing against adversarial as well as ordinary inputs, monitoring of its answers, and a clear route to a human. For most organisations, internal agents are the right place to build experience before considering external ones.

How do we know whether a custom agent is worth it?

Measure the pattern it replaces. A good agent reduces a recognisable stream of repeated questions to a person or team, so track how often those questions still arrive, how much the agent is used, and how often users flag wrong answers. Combined with Copilot utilisation across licensed users, this gives evidence of value that is more convincing than general satisfaction surveys — an approach set out in our guide to measuring Copilot ROI. Agents that are rarely used after the first month should be improved or retired rather than left in place.

Related reading

More guidance on governing and getting value from UK business technology:

• AI agent reliability: testing autonomous workflows
• Azure identity and access management: securing admin access
• Microsoft 365 email archiving and eDiscovery
• Internal versus external penetration testing
• Cyber Essentials and insurance: how certification affects premiums