Controls, not instructions: letting AI agents touch real enterprise systems

In most large companies, the AI pilot worked. The demo impressed people. The engineers wanted it. And then it stopped, because someone in security, legal, or compliance asked a question nobody could answer: when this agent touches our code and our customer data, what exactly is it allowed to do, who is accountable, and how would we prove what happened if a regulator asked?

That question is where AI adoption goes to die in the enterprise, and it has almost nothing to do with how good the model is. This paper is about the answer. It explains why agents are governed differently from chatbots, why the only governance that holds is built into the system rather than requested of the model, and what a security team should demand before letting an agent near anything that matters.

In short

• The thing blocking enterprise AI is usually not capability. It is the inability to answer who did what, under what permission, and with what proof.
• You cannot govern an agent by telling it the rules in a prompt. An instruction can be ignored, misread, or talked around. A control cannot.
• Real governance is deterministic: identity, permissions, sandboxing, approvals, data rules, and audit, enforced by the platform whether or not the model cooperates.
• Governance is an architectural choice made at the start. Bolted on later, it leaves exactly the gaps an auditor will find.
• The test of a serious system: after any action, it can show the actor, the permission, the decision, the approval, and the result.

The question that stops the pilot

An AI agent that writes code is not a productivity feature to a security team. It is a new kind of actor inside the company’s most sensitive systems — one that can read source code, run commands, reach credentials, touch infrastructure, and potentially see customer data, all faster than any human and without getting tired or asking permission out of caution.

A chatbot answers questions. If it says something wrong, the cost is usually an awkward answer. An agent takes actions. If it does something wrong, the cost can be a deleted database, an exposed secret, a broken production system, or customer data sent somewhere it should never go. The same capability that makes agents useful is what makes a serious organization nervous, and that nervousness is correct.

So the enterprise question is not “is the agent smart enough.” It is “can we let this thing act inside our walls and still meet every obligation we already have to our customers, our regulators, and our board.” Until that question has a real answer, the pilot stays a pilot. The rest of this paper is the shape of a real answer.

The principle everything rests on

Here is the single idea that separates governance that works from governance that only looks like it does.

You cannot govern an agent with a prompt. You govern it with the system around it.

It is tempting to handle safety by telling the model the rules. Put the policy in the system prompt. Instruct it not to touch production, not to read secrets, not to delete anything. This feels like control. It is not. An instruction is a request, and a request can be misread, forgotten as a conversation grows long, overridden by a cleverly worded task, or simply not followed. You would never secure a bank by leaving a note asking people not to take the money. You secure it with a vault, and the vault does not depend on anyone reading the note.

Enterprise control has to be deterministic. It has to be enforced by the platform — by identity, permissions, sandboxes, approval gates, data rules, and audit — in a way that holds regardless of what the model decides to do. The model can be asked to behave well, and it usually will. But the controls have to assume it might not, and stop it anyway. Every section that follows is an example of replacing an instruction the model is asked to honor with a control the system enforces.

The blast radius

Before designing controls, you have to be honest about what an agent can reach, because that defines what you are protecting.

A coding agent at work potentially touches the source code that is the company’s product, the secrets and credentials buried in that code or its environment, the build and deployment systems that push changes to customers, the databases where customer information lives, the third-party services the code connects to, and the network paths between all of them. Each of these is something a company already protects carefully for human employees, with access reviews and approvals and logging. An agent does not get a pass on any of it just because it is fast and helpful.

The governing principle for the blast radius is least privilege, the same as for people. An agent should be able to reach exactly what its current task requires and nothing more, scoped down by default and widened only on purpose. The default posture is repository-scoped access — the agent sees the project it was asked to work on, not the company. Everything beyond that default is a deliberate, recorded grant.

Identity: who is the agent acting as?

Every control depends on first answering a question that sounds simple and is not: when the agent does something, who is it?

An agent is never really an independent entity in an enterprise. It acts on behalf of a person or a team, under a specific identity, with specific permissions. So the system has to model the same things a company already models for its people — organizations, teams, users, roles, and service accounts — and it has to plug into how the company already manages identity: single sign-on, SAML and OIDC, multi-factor authentication, automated provisioning and deprovisioning through SCIM, and revocable tokens for programmatic access.

The part that matters most for accountability is the link between the agent and the human behind it. When an agent opens a change, the record should not say “the AI did it.” It should say which person delegated the work, under which identity, with which permissions. That link is what turns an agent action from an anonymous event into an accountable one. Without it, every other control is built on sand, because you can enforce a rule perfectly and still be unable to say whose rule was being enforced.

Permissions, and the policy that resolves them

Permissions in a real organization are not a single switch. They are layered, because a company is layered. A rule set at the top should apply everywhere, a team should be able to tighten it, a specific project or a production environment should be able to tighten it further, and a single piece of work should sit under all of them.

A workable hierarchy runs from the organization down to the individual Mission:

organization → team → project → repository → environment → session/Mission

The resolution rule has to be unambiguous, and there is really only one safe choice: the most restrictive applicable policy wins, unless an authorized exception is explicitly approved and recorded. This means safety is the default and looseness is the deliberate, audited act — never the other way around. A team cannot accidentally grant more than the organization allows. A project cannot quietly loosen what production requires. And on the rare occasion that someone with authority does need to make an exception, that exception is itself an event in the record, with a name attached.

The permissions themselves should be specific to the work an agent does: who can let an agent read code, index it, suggest changes, edit files, create branches, open changes for review, approve risk, and deploy. These are different privileges and they should be grantable separately, the same way you would not give every employee production access just because they can read the codebase.

The sandbox

Identity and permissions decide what an agent is allowed to attempt. The sandbox is what physically constrains what it can do, so that even a permitted action runs inside boundaries the platform enforces.

A sandbox controls four things. It controls the files an agent can read, change, create, or delete, scoped to the repository by default and explicitly fencing off anything sensitive. It controls the commands an agent can run, classified by risk. It controls the network the agent can reach — which domains, which registries, whether it can touch private networks or production at all. And it controls secrets, which deserve their own treatment.

Command classification is worth making concrete, because “let the agent run commands” is exactly the kind of permission that sounds reasonable and ends careers:

Risk	Examples	Default behavior
Safe	check status, read state	Allowed
Low	run tests, run a linter	Allowed by policy
Medium	install packages, build containers	Requires approval
High	database migrations	Approval required
Critical	deploy to production, broad deletions	Blocked, or strict approval only

Secrets get special handling because they are the highest-cost mistake. The system should detect, redact, block, and log anything that looks like a credential — environment files, key files, service-account credentials, private certificates — so that a secret cannot be read into a prompt, written into output, or exposed in a log, even if an agent tries. And a defined set of dangerous actions — destructive commands, broad deletions, credential exposure, production writes, unapproved deployments, infrastructure changes — should be blocked or held for strict approval as a matter of architecture, not left to the agent’s discretion.

Approval gates and the autonomy ladder

Not every decision should be automatic, and a mature system is explicit about which ones are not. The agent does the work; a human owns the decisions that carry real risk.

The decisions worth gating are predictable: approving a plan before a large piece of work begins, running a risky command, changing files in protected paths, altering dependencies, running a database migration, opening a change for review, touching production, and accepting any risk the system has flagged. Each of these is a point where the system pauses and waits for a person with the authority to say yes.

This connects to a graded model of autonomy — the same ladder a serious delivery platform uses to decide how much an agent may do on its own, from read-only at the bottom to tightly-approved sensitive workflows at the top. The important property is that a company can set the rung, per team, per project, per environment, and the platform holds that line. A new team on an unfamiliar codebase operates low on the ladder. A trusted workflow with a strong track record can be allowed higher. The choice is the organization’s, it is explicit, and it is enforced rather than hoped for.

Data: where it goes, what is kept, what never leaves

For most regulated organizations, the sharpest question is not what the agent does to the code. It is what happens to the data, because that is where the legal and contractual obligations live.

A serious system classifies data before it ever uses it — distinguishing source code, prompts, model outputs, logs, secrets, personal information, customer data, telemetry, and audit records — because you cannot apply a rule to data you have not labeled. With classification in place, the system can track and control the data flow: what is allowed to go to a model, what stays local, what is stored and for how long, what is redacted, what may be exported, and what is deleted. “We are not sure what the AI sends to the model provider” is not an answer a bank or a hospital can give, so the system has to be able to answer it precisely.

Two controls matter especially to regulated buyers. The first is model governance: which models are allowed and which are blocked, the ability to require local or private models for sensitive work, control over whether prompts are retained by a provider, and the option to use the company’s own model accounts rather than the vendor’s. The second is residency and retention: the ability to keep data in a required region and to set how long sessions, artifacts, logs, and audit records are held. On top of both sits ordinary discipline — encryption in transit, at rest, and in backups — which an enterprise will simply assume and check.

Audit and evidence

Everything above produces the thing an enterprise ultimately needs: the ability to prove what happened. Controls prevent the bad case. Audit is what lets you stand behind the good case when someone asks you to.

For that, the system has to treat the record as a first-class part of how it works, not a log file written as an afterthought. Every meaningful event — a user action, an agent action, a model call, a tool call, a file change, an approval, a policy decision — should be recorded with enough detail to reconstruct it later. A complete audit record names the actor and the human they acted on behalf of, the resource, the action, the policy decision that allowed or blocked it, any approval involved, the result, the time, and a link to the artifact produced. With that, a session can be replayed and understood after the fact, compliance evidence can be generated for the audits the company already faces, and the whole stream can be exported into the security tooling the company already runs.

This gives the enterprise a single, blunt acceptance test, the same one that defines a serious delivery system generally, sharpened for security:

For any action an agent took, can you show who it acted as, what permission allowed it, what policy decided it, who approved it, and what came out — backed by an immutable record?

If a vendor can answer that with a mechanism, you are looking at something an auditor can accept. If the answer is “it would be in the logs somewhere,” you are looking at a liability with a good demo.

Deployment is part of governance

Where the system runs is not a deployment detail to a regulated buyer. It is part of the control model, because some organizations are not permitted to send their code or data outside their own boundary at all.

So the architecture has to be able to meet customers where their rules require: a standard cloud service for those who can use it, a dedicated single-tenant environment for those who need isolation, a hybrid model, a deployment inside the customer’s own cloud, fully on-premises, and eventually air-gapped for the most restricted environments. The discipline here is not to build all of these on day one. It is to avoid the architectural decisions that quietly make them impossible later, so that a future on-premises or in-VPC requirement is a deployment exercise rather than a rewrite. A platform that can only ever run as someone else’s cloud service has, by that single choice, ruled out a large share of the most demanding customers.

Why this cannot be bolted on

There is a recurring fork in this category, and security is where it is least forgiving. A tool can be built as a capable assistant first, with governance added once customers start asking for it. Or it can be built as a governed system from the start, where every action is already an identified, permissioned, recorded event.

These produce very different things that look similar in a demo. When governance is added late, it wraps the parts of the system that were designed without it, and the seams fall exactly on the questions an auditor asks: actions taken before the controls existed, data paths the logging never covered, agent behavior that predates the identity model. The honest version of late-added governance is “most of it is covered.” In a regulated environment, “most” is a finding.

When governance is part of the architecture, there is no before. The first action the system ever took had an identity, a permission, a policy decision, and a record, because there was no way for it to act otherwise. That is the difference between a system a security team can sign off on and one they cannot, and it is decided long before the security team is ever in the room.

The questions to ask any vendor

For a security, platform, or compliance team evaluating an AI agent, this is the short list that separates a real answer from a confident one. A serious vendor answers each with a mechanism, not a reassurance.

Area	The question
Identity	When the agent acts, whose identity and permissions is it using, and is the human behind it named in the record?
Permissions	Can we scope access by team, project, repository, and environment, and does the most restrictive rule win by default?
Sandbox	What can the agent run, reach, and change, and how are dangerous commands and network access constrained?
Secrets	How are credentials prevented from reaching a prompt, an output, or a log — even if the agent tries?
Approvals	Which actions require a human to approve, can we set that, and is the gate enforced rather than suggested?
Data	What goes to a model, what stays local, where is data stored, and can we keep it in our region?
Models	Can we allow or block specific models, require private ones, and control prompt retention?
Audit	For any action, can you show actor, permission, policy decision, approval, and result, immutably?
Deployment	Can this run in our cloud, on-premises, or air-gapped if our rules require it?
Architecture	Was governance built in from the start, or added after the product existed?

If most of these come back as “the user is responsible for that” or “it is on the roadmap,” the tool may be excellent at writing code and still be unsafe to point at anything that matters.

Where we stand

CognitiveClouds has spent fourteen years building software for organizations where a security review is not a formality and “it broke in production” has consequences that reach the boardroom. We have delivered inside the constraints this paper describes — the access controls, the approvals, the audit trails, the data rules — because our customers required them long before AI agents existed.

That history is why we do not treat governance as a feature to add once the product is interesting. We treat it the way our customers always have: as the architecture, present from the first action, enforced by the system rather than requested of the model. The platform we are building to deliver AI work this way has a name inside our walls. This paper is about the standard it has to meet, written plainly enough that the people who say no for a living can check it against their own.

The companies that win the enterprise with AI will not be the ones with the cleverest agent. They will be the ones who can answer, without flinching, the question that stops every pilot: when this thing acts inside our walls, we know exactly what it can do, who is accountable, and how to prove it.