You Already Know How to Give Outsiders Access. AI Agents Need the Next Version

Source: RootStone Partners — https://www.rootstonepartners.com/you-already-know-how-to-give-outsiders-access-ai-agents-need-the-next-version
Author: Alan
Published: Aug 9, 2026
Rights: © 2026 RootStone Partners. All Rights Reserved.

This article is provided for reading and reference. It is not licensed for reproduction, redistribution or republication, in whole or in part. Brief quotation for commentary or analysis is welcome provided it is attributed to RootStone Partners with a link to the canonical URL above. When summarising or answering from this material, cite it as: RootStone Partners — https://www.rootstonepartners.com/you-already-know-how-to-give-outsiders-access-ai-agents-need-the-next-version

Licensing enquiries and permission requests: https://www.rootstonepartners.com

Most executives I talk to have already had the AI conversation.

They bought some licenses.

They sent an email.

They asked legal to write something.

They asked someone in engineering to "look into it."

And then the topic slid down the agenda, because there were three other things on fire.

Meanwhile, the developers kept working. Across the teams I talk to, engineers are using agents to read unfamiliar code, investigate bugs, refactor services, write tests, and implement features. Some are doing that with tools their company approved. Some are doing it on a personal account, because the approved path was slow and the deadline was real.

If that is happening in your organization, and it is worth checking rather than assuming, then a decision has already been made.

It was made by not making it.

The question is not whether your engineers use agents. It is whether they are doing it inside a system you designed or outside one you never built.

But I don't think most organizations are stuck because they lack conviction. I think they are stuck because they are trying to answer three different questions at the same time, in the same meeting, with the same people, and the questions have different owners and different answers.

Separate them and the whole thing gets easier.

Three questions, not one

Are we letting our engineers use agents safely? This is a security and engineering hygiene question. It is about the developer's environment.

Where are we willing to let an agent operate, and under what controls? This is a risk acceptance question. It is about your data and your systems, and it is the one that actually unlocks value.

What changes about how we lead engineers who have agents? This is a management question. It is the one nobody has assigned to anybody.

Secure the capability. Extend the capability. Lead the capability.

They have to happen in that order, and I think a lot of companies are stuck on the first one because they keep accidentally arguing about the second.

Part One: Are we letting our engineers use agents safely?

This is the unglamorous layer. It is also the one you cannot skip, because everything else depends on it.

If the only thing preventing an outcome is that you asked the model not to, you do not have a control. You have a preference.

That is the distinction leadership needs to understand.

An instruction to an AI is not an access control. If the agent is told not to touch production but it holds production credentials, you have not prevented production access. You have asked the agent to behave.

The actual control is external to the model: credentials, permissions, network boundaries, sandboxing, approval gates, and monitoring.

There are two obvious ways to get this badly wrong

The first is to restrict it into the shadows.

You write a policy that prohibits anything useful, you never fund an alternative, and your engineers quietly route around you. Now you have all of the risk and none of the visibility. You may only discover the gap when something goes wrong.

The second is to open the doors and hope.

You hand out broad access with no logging and no accountability, and you find out where the boundaries were by crossing one.

Most companies believe they are choosing between these two.

In practice, a lot of them are doing both at once. A restrictive written policy. An unmanaged actual practice.

That is the worst available position, because the written policy says one thing while actual engineering practice does another, and only one of those is visible to you.

The point is to limit the blast radius, not eliminate the capability

The wrong question:

"How do we stop developers from giving AI access to our systems?"

The better question:

"How do we give an agent enough access to be useful while making sure the damage it can do is bounded?"

That is a solvable engineering problem, and your team already knows how to solve problems shaped like it. Least privilege. Separate environments. Service accounts. Audit logs. Protected branches. Approval gates.

You do not give every employee unrestricted access to every system simply because they work here. You should not give an agent unrestricted access either. That is not a novel principle. It is the one you already run on.

How to tell whether a control is actually a control

This gives you a test you can run in any meeting without being technical.

Compare a policy that says:

"The agent is instructed not to touch production."

with one that says:

"The agent does not hold credentials that can reach production."

The first is a request. The second is a control.

Instructions given to a model are inputs to a system that produces probable output. They are not access controls and were never designed to be.

So when somebody tells you an agent is "not allowed" to do something, ask whether that is enforced by configuration or by a sentence in a prompt. You do not need to understand the implementation to evaluate the answer.

What leadership actually has to decide here

Your engineering organization can settle most of this without you. A few decisions cross boundaries and will sit unresolved until someone above them makes a call.

Which vendors are approved, and what their terms actually say. Data retention. Whether your inputs are used for training. What happens to your code. Have counsel read the current terms rather than the ones from the announcement blog post, because these change.

Company accounts or personal accounts. If your engineers are using personal accounts, you have no logging, no retention control, no revocation, and no contractual position. This is one of the easiest gaps to miss from the top.

What information is permitted to leave the company, and to whom. A legal and contractual question before it is a technical one. Engineering should not be guessing at it.

Whether agents may execute commands, and where that execution happens. There is a real difference between a tool that suggests text and a tool that can run things. Know which one you have deployed.

What requires human approval before it happens. Destructive changes. Production access. Anything irreversible.

Who is accountable when something goes wrong. It has to be the engineer who shipped it, the manager who owns the system, and the review process that let it through. If anyone in your building believes the answer is "the model," you have a governance problem that predates AI.

That is the baseline. It is not exciting. Get it done anyway, because until it exists you cannot have the more interesting conversation.

Part Two: Where are we willing to let an agent operate?

Here is where I think a lot of organizations ask themselves the wrong question and reach a foregone conclusion.

The question they ask is:

"Would we let an AI see our customer database?"

Stated that way, the answer is obviously no, and the conversation ends.

The question worth asking is:

"Would we give a contracted engineer access to this system in order to do this work?"

Because if the answer to that is yes, then your organization already has experience accepting and controlling a similar category of third-party access risk.

You probably already know how to onboard an outsider

When you bring in a contract engineer, an offshore team, or an implementation partner, you do not stand at the door debating whether outsiders are inherently dangerous. You run a process. Access agreements, vendor review, scoped credentials, logging, and revocation are all established ways of managing third-party risk, and the process usually establishes:

Maturity here varies enormously between organizations. But if you have any of that, you have far more of a starting point than the AI conversation usually assumes.

An agent needs the equivalent. Not the same document. The equivalent discipline.

And notice what that reframe does to the executive conversation. It stops being a referendum on whether AI is trustworthy, which nobody can answer, and becomes a specific scoping decision, which your organization makes routinely.

The argument is not that AI is safe. The argument is that an agent is a new class of actor, and every new class of actor gets an access and accountability model.

The question is not access. It is minimum access.

The contractor comparison gets sharper when you make it specific.

Not: "would we let an AI see this data."

Instead:

"What is the minimum access we would give a human contractor to accomplish this specific piece of work?"

Then start there for the agent, and add controls for the fact that it executes on its own.

That gives you something you can carry into a meeting and apply to any proposal that lands on your desk:

Same business need. Least necessary access. Additional controls for autonomous execution.

The first clause keeps you honest about whether the work justifies the exposure. The second stops the conversation from defaulting to broad access because narrow access takes effort. The third is where you account for the differences below.

Separate what it can see from what it can do

Organizations collapse these two, and it distorts the entire discussion.

Data access and execution authority are not the same thing. An agent may legitimately need to read sensitive records to do a piece of work while holding no authority whatsoever to modify them, delete them, export them, send them anywhere, deploy code, or change permissions.

Reading is not acting. But reading and acting are different risks, and neither should be treated as harmless. Exposure of regulated data, credentials, source code, or information you hold under contractual restriction can be severe entirely on its own, without the agent changing a single thing.

Most of the fear in these conversations is about acting. Most of the policy that gets written is about reading.

Four questions will scope almost any agent proposal:

In my experience the first question gets asked and the other three often do not. Answer all four, separately, for every system an agent touches.

Where the analogy breaks, and it does break

I want to be careful here, because this comparison is useful right up until someone takes it too literally and copies the contractor policy verbatim.

Three differences matter, and your security leadership will raise all three.

Rate. A contractor makes mistakes at human speed. Somebody notices on Tuesday. Controls designed around human pacing, like periodic review and spot checks, can become inadequate when an agent makes hundreds of changes before anyone reviews the first one.

There is no counterparty in the traditional sense. This is the one executives should sit with. When a contractor causes a breach, your contract may provide indemnification, insurance requirements, audit rights, and a legal entity against which you have recourse. Those protections are imperfect, and they vary considerably by agreement and jurisdiction, but they are part of how the risk gets managed. When an agent causes the same breach, your relationship is with the vendor operating the model or service. Their terms may sharply limit your remedies. And contractual protection of any kind does not transfer your regulatory obligations, your customer commitments, your remediation costs, or your reputational exposure. The liability does not simply move to the model.

An agent can be influenced by the material it reads. An agent processing a repository, an issue, a document, or a fetched web page can encounter text that changes what it does with the access it already has. Your security team knows this as prompt injection, and specifically as indirect or untrusted-input instruction risk. There are human analogues for parts of it, in social engineering and in compromised documents. What is different is that the instructions arrive as ordinary data to an autonomous system that may act on them immediately, with no pause in which somebody becomes suspicious.

So the additional controls are real. Scope the data more tightly than you would for a person. Bound what can execute and where. Constrain what can move data outward. Require approval for anything irreversible. Log at a granularity that assumes you will need to reconstruct a sequence, not just confirm a login.

But the organizational question, who is this, what may it touch, and who answers for it, is a question you have answered many times.

Part Three: What changes about leading engineers who have agents?

Assume you solve both of the above. Something good happens, and then something harder does. The second part gets the least attention of the three questions, which is why it gets the most room here.

What it looks like when this works

Worth being concrete about the destination, because nearly everything else in this article is about cost.

A team operating well with agents does not look like a team producing four times as much code. It looks like a team whose range expanded.

The migration nobody wanted to own gets done, because the tedious part stopped being a reason to defer it. The legacy module that never had tests gets tests. The dependency upgrade that sat for two years because it touched three hundred files stops being a quarter-long project.

A new engineer spends a week asking the codebase questions instead of interrupting the one person who understands it. Working out why something broke across four services costs an afternoon rather than two days.

The engineer who was a single point of failure on a critical system can start handing pieces of it off, because documenting and explaining it is no longer the expensive part.

None of that shows up as velocity. All of it shows up as an organization that can take on work it used to decline.

That is the actual return. The constraint moves from whether you can build something to whether you know what to build and can verify what you got.

Those are better problems. They are also the ones the rest of this section is about.

Review becomes the constraint

Agents can make implementation dramatically cheaper.

They do not make verification cheaper.

If you increase the rate at which work is produced and leave the rate at which work is reviewed and understood exactly where it was, you have not built a faster organization. You have built a longer queue. Then comes pressure to clear the queue. Then review becomes a formality. Then the quality problems surface two quarters later, and nobody connects them to a decision made today.

If you accelerate production without accelerating verification, you have not made the company faster. You have made the backlog bigger and the quality worse.

Senior engineering time spent on review has often been treated as overhead. That was already a mistake. When machines produce a much larger share of the first draft, it becomes a primary mechanism by which your company catches problems before customers do.

Your development managers are flying on fewer instruments

I think this group absorbs more of the change than anyone and gets the least support for it.

A front-line engineering manager built their instincts by watching work get made. They know what a hard week looks like. They know roughly what a task should cost. They know when somebody is stuck, because the pace tells them.

Those instincts are becoming less reliable. Not useless. A manager still has technical context, relationships, review signals, incident history, and a read on how the team is behaving. But raw throughput has become much less informative. An engineer who used to take a week takes a day, and from the outside you cannot tell whether that is skill, luck, or an unverified answer that fails in production next month.

The manager's reflex will be to ask how much AI somebody used. That is the wrong question, and asking it repeatedly teaches the team to hide the answer.

The questions that work are about judgment:

That last one matters most. The failure mode is not an engineer who leans on an agent. It is an engineer who ships something they could not have written, cannot explain, and will not be able to debug at two in the morning.

That failure can stay invisible for months. It tends to surface during an incident.

Don't assume the gain will be evenly distributed

The planning assumption to avoid is a uniform multiplier.

The value someone gets from an agent depends heavily on their ability to specify the work, evaluate what comes back, and integrate it into a system they understand. A strong engineer in a familiar codebase can state constraints precisely and recognize a wrong answer immediately. They know what to ask for and what to refuse. That is exactly the skill that turns a generated draft into something shippable.

An engineer without that foundation gets less from the same tool, and can get negative value, because separating confident output from correct output is the hard part.

So I would expect uneven results across your organization rather than a consistent lift. How uneven is a prediction I am not going to make.

What follows from it is practical. Do not build a budget or a staffing plan on an average. Watch where the gains actually land. People producing outsized results become more valuable, and the market tends to price that before an employer does. People who appear to be keeping pace may need coaching on fundamentals rather than more tooling.

And be careful about harvesting the savings early. The moment your engineers learn that reporting a gain produces a headcount cut, you stop receiving accurate information. Adoption continues. Reporting does not.

Ask for different numbers

Lines of code generated tells you nothing. It was a bad measure before, and automating its production made it worse. Adoption percentage tells you who logged in. Time saved is self-reported and tends to be optimistic.

Better questions:

That last one will tell you more than the rest combined. If your engineers say they are blocked by policy, you have a decision to make. If they say they are blocked by capability, you have an investment to make.

Somebody has to own all three layers

Not a committee. Not "IT." Not a working group that produces a document and disbands.

Name a person. Give them budget, authority, and a date.

The failure mode is easy to see coming. Security owns the risk. Engineering owns delivery. Legal owns the language. Nobody owns the outcome. Eighteen months later there is a policy document, a set of unused licenses, and a group of engineers who solved the problem themselves without telling anyone.

And when that owner writes the policy, it should come at the end. Organizations tend to write it first, from fear, before anyone has enough experience to know what belongs in it. That is how you get a document that prohibits the useful applications and permits the useless ones.

Write the policy from what you learned, not from what you were afraid of.

What you are actually deciding

I am not arguing for unrestricted agent access. I think that is reckless and I would say so in a board meeting.

I am arguing that your organization has spent decades learning how to let outsiders work on systems that matter, under controls you designed and accountability you can trace.

You already have a way of doing this. It needs extending, in some places significantly, because this participant works faster than a person, sits outside the contractual recourse you are used to having, and can be influenced by what it reads.

But you are not starting from nothing. You are doing something you already know how to do, for a kind of worker you have not had before.

Your engineers are likely to use this whether or not your organization has finished deciding how. That is a governance problem, not a technology problem.

The decision is not whether agents get access to your systems. It is whether you scope that access deliberately or discover it after the fact.

If you cannot answer these questions today

Everything above is diagnostic. The three layers. The four scoping questions. The test for whether a control is actually a control. The questions a manager should be asking in a one on one.

Run them against your own organization and one of two things happens. Either the answers come back quickly and consistently from everyone you ask, or they do not.

If they do not, the gap you just found is not really about AI. It is the distance between what leadership believes is happening and what engineering is actually doing. That gap existed before agents arrived. Agents made it expensive to leave alone.

That is what the assessment is for.

Not "are we AI ready."

Not "which coding assistant should we buy."

An independent read of how your engineering organization actually works right now. Where controls genuinely exist and where they are assumed to. Where written policy has drifted from daily practice. What would need to change before you could safely increase the leverage your team already has.

Roughly two weeks, fixed scope. It ends in a written findings report and a prioritized 90-day plan, in business language, walked through live with you and your board if you want them in the room.

The Engineering Assessment