# You Can't Least-Privilege a Goal

* * *

Every access model we have built over the last thirty years rests on one assumption: the thing holding the credential has a job.

A person has a role. A service account supports a defined workload. Those assumptions were never perfect, but they were stable enough to hang an entire discipline on. Roles, entitlements, approval chains, quarterly access reviews, periodic cleanup. All of it works because a job is a bounded, repeatable set of actions, and you can write policy around bounded things.

An AI agent does not have a job. It has a goal.

That distinction sounds academic until you sit with what it breaks. An agent interprets instructions, selects its own tools, and adapts what it does based on context it encounters at runtime. Two agents provisioned with identical permissions can carry completely different risk profiles, because the risk lives in what each one is trying to accomplish, not in the scope attached to its token. Your entitlement report will show them as twins.

## The maturity curve most teams are stuck in the middle of

Agent security moves through three phases: adoption, then visibility, then control. Most organizations I talk to are somewhere in phase two, and phase two feels deceptively like progress because it produces a dashboard.

Finding the agents is a genuine first step. They arrive embedded in SaaS platforms, developer environments, cloud workflows, customer support tooling, productivity suites, and internal applications. Some are sanctioned. Many are not. Nobody filed a ticket to provision the coding assistant that now has a personal access token and commit rights.

But an inventory is a census, not a control. Knowing that forty-three agents operate across your environment tells you nothing about whether the one wired into your deployment pipeline should be allowed to touch production secrets at 3 a.m. because it decided that was the shortest path to the outcome you asked for.

### Why this lands on engineers, not the GRC team

If you work at a company with a dedicated identity governance function, this is a program problem. If you work at the other 95% of companies, it is a Tuesday.

The person who grants the agent its credential is usually the person building with it. There is no intake process, no architecture review, no separation between the developer wiring up the integration and the operator accountable for what it can reach. That collapse of roles is the actual SMB exposure here, and it is the same structural gap that shows up in every incident where an autonomous process escalated from a narrow task to broad lateral access over a weekend.

Enterprise language describes this as governance. At smaller scale it is simpler and more uncomfortable: one engineer, one API key, and no one watching the loop.

* * *

### \_\_ Security Considerations \_\_

**../ Permission scope no longer predicts behavior.** Static entitlements were a reasonable proxy for risk when identities had fixed workloads. Agents adapt at runtime, so two identically scoped agents can diverge sharply in what they actually do. Reviewing permissions tells you what is possible, not what is likely.

**../** **Discovery consistently outruns governance.** Agents enter through product features and developer tooling rather than through IAM provisioning. By the time an agent appears in an inventory, it has usually been operating for weeks with credentials nobody formally approved.

.**./ Review cadence is calibrated to human tempo.** Quarterly access reviews and periodic cleanup assume that access drifts slowly. Agents act continuously and at machine speed. A control that catches over-privilege ninety days late is documentation, not enforcement.

### \_\_ Mitigation Strategies \_\_

**:: Bind authorization to purpose, not just scope.** The workable control plane has three dimensions rather than two: identity establishes who the agent is, permissions establish what access exists, and intent establishes why that access should be active right now. Constrain high-risk actions by the agent's role, owner, assigned task, environment, and expected outcome. This is not manual approval of every call; it is conditional access with purpose as a condition.

**:: Make registration a precondition of deployment, with a named human owner.** Every agent gets an accountable person attached before it gets a credential. That single requirement closes most of the discovery gap, because it moves the control to the moment of creation instead of the moment of audit. If no human will put their name on it, it does not ship.

**:: Enforce before, during, and after the action.** Pre-authorization at invocation, runtime constraint on the small set of genuinely high-risk operations, and post-action attestation that produces a reviewable record. Humans set the thresholds and hold the authority to change them; the system executes continuously against those thresholds.

* * *

## The question that reframes the whole program

The sharpest line in the source piece is a reframe of the security team's default posture. Stop asking what should be removed after risk is detected, and start asking: "What should this agent be allowed to do in the first place?"

That is a shift from detection to design, and it is the same argument I made in [Patching Is Dead. Judgment Isn't.](#) from a different direction. There, the bottleneck was decision latency: not scanning speed, but how long it takes an accountable human to authorize a response. Here, the bottleneck is decision placement: whether the judgment happens before the agent acts or in the forensics afterward.

Both point at the same architecture. XaaSWare**™** **Human-in-the-loop**, where a person approves every action, collapses under agent volume. Fully autonomous collapses the first time an agent optimizes its way into your cluster. Human-on-the-loop is the working answer: machines execute continuously within boundaries that accountable humans define, own, and can revoke.

The OWASP Top 10 for Agentic Applications names the failure modes plainly enough that they belong on a whiteboard: identity and privilege abuse, tool misuse, insecure inter-agent communication, cascading failures. Every one of them is a governance failure expressed as a technical incident.

Agents are going to write code, manage infrastructure, move data, and execute workflows across your stack. The teams that come out of this intact will not be the ones with the most complete agent inventory. They will be the ones who understood their agents well enough to constrain what those agents can do.

**Who owns the agent with the broadest permissions in your environment right now? If the answer takes more than a minute to find, that's the finding. Looking on how to De-Risk Artificial Intelligence for your SMB? eMail: GRC\[**at**\]XaaSWare.io or by calling 844.247.XaaS**

* * *

#XaaSWareHOTL #AIAgents #Cybersecurity #ZeroTrust #DevSecOps

/ag