Most security programmes were built to put controls around risks that are well established and relatively slow moving. AI agents are not that, and they are changing quickly enough that the control you need for a given risk often isn't sitting in the framework yet. An agent is only useful once it can reach the systems that matter to a business, and that reach is exactly what turns adoption into a governance question, not just a technical one.
Why avoidance doesn't work
Faced with a risk that is hard to pin down, the easiest response looks like holding back until it feels safer. Avoiding AI adoption doesn't guarantee people stop using it. Sometimes it just pushes the work onto a personal account instead, with no visibility into what data goes in or how it's used. Saying no doesn't stop the use, it just moves it into shadow accounts.
Enable before you control
The better approach stages the rollout rather than trying to anticipate every use case up front. Adopting AI plays out as a maturity story rather than a single policy decision. ClearPoint, for example, rolls new tools out on the permissive end, then shapes the controls around how the organisation actually uses them. Every rollout surfaces risks that weren't on the original list.
The same pattern applies to integrations. An agent only starts delivering real value once it can reach the core systems that run the business. This is also where the risk concentrates. That makes it worth running a risk assessment before any of those integrations is turned on, and piloting each one before it's rolled out more broadly.
Tools built for this, like Claude Cowork, already isolate each session to a single folder and leave the choice of what else it can reach entirely up to the user. Cowork's enterprise controls are being layered in over successive releases, so early adopters work with a smaller set of controls now and expand them as more become available.
How adoption actually takes hold
The people running a business process are the ones who know where the friction sits and where the savings could come from. When those same people have the tools and the permission to try things, the valuable use cases come from them rather than from a leadership team reviewing the process from above.
Support from the top is not the same as pressure from the top. Support builds the culture and gives people permission to experiment, while pressure stifles the discovery before it starts. At ClearPoint,the guardrails went in first, then people were actively encouraged to use AI, with a clear expectation that the business wanted to be a frontier firm. The rest happened on its own once people started seeing what AI could do for their own work, and it’s now part of everyday work across the business.
Extend what you already have
Businesses already scope access when a new supplier or a new employee comes on board. An AI agent can be handled the same way, with its own identity and only the access its job requires. An agent almost never needs to run under a superuser account. Keeping it scoped to what the job actually needs means a mistake stays contained to what that identity could reach, rather than spreading across the whole business.
Information security standards like ISO 27001 already provide that discipline. Policies get checked rather than just written, and access reviews happen on a schedule rather than only when someone remembers. Training doesn't catch everything, so moving the checks into delivery pipelines, where they run on every change, adds another layer. An agent simply needs to sit inside that same discipline, not one built specifically for it.
Being upfront with clients
For any business that works with client data, the concern that comes up most is intellectual property. Clients are giving access to critical documents and code, and they need to know that material won't end up training a model or sitting in a system long after the engagement ends.
If AI is part of how you deliver, the time to set out how a client's data will be used is at the start of an engagement, before any work begins. Where a client wants their work kept to particular models, that can be agreed upfront and held to. AI clauses in standard agreements make the use transparent and give the client the ability to opt out, for a specific piece of work or a specific dataset.
The risk sits in the integrations
The worry with each new integration is data leaking from key data sources into the models, including client data, and where it ends up after that. Those same integrations are what make agentic workflows worth having, so they get opened up in a measured way rather than all at once.
The board-level question
AI agents are already operating inside real systems. The boundaries around what they can do are worth setting as deliberately as the decision to use them in the first place.
The right question at the board level isn't whether AI is safe. It's how the business is using AI to innovate the business model, and how it's using AI to deliver more efficiently to clients. Scoping what each agent can reach, being upfront with clients about their data, and starting the highest-risk integrations on a pilot basis are the moves that let leaders answer that question with confidence rather than caveats. None of it removes the risk entirely, so what matters is the layers you have in place and knowing what you are left carrying once they are there.
