As AI expands the volume and autonomy of enterprise activity, unnecessary access is becoming harder to tolerate and justify. AI identity security needs a measurable outcome: less authority available for misuse, and verified containment when something goes wrong.
The urgency comes from the access we’re granting today. AI agents can act across connected systems, using permissions that may outlast the task they were created for. Every deployment needs enforceable limits and a tested way to withdraw access. Otherwise, we’re expanding what automation can do faster than we’re proving we can contain it, and creating a foundation of invisible trust chains and obfuscated touchpoints.
A roadmap can authorize the work. It can’t revoke a credential.
2026 evidence
In its July 2026 intrusion analysis, Hugging Face reconstructed approximately 17,600 attacker actions across a 4.5-day campaign, including roughly 2.5 days inside its infrastructure.
That particular incident involved an evaluation with reduced safeguards, not a universal benchmark for AI attacks. Nevertheless, the combination of automated exploration, stolen credentials, and movement across systems deserves serious attention and should be a wake-up call. Execution policies also blocked attempted supply-chain changes. Controls mattered then, and will matter in the future, and we need them now, not retrospectively after an attack.
We face two related problems:
- attackers automating intrusion, and
- legitimate agents exceeding their intended authority.
Both make the principle of least privilege an operational priority.
Standing privileges expand the damage
Let’s consider a hypothetical analytics agent that needs to query approved tables. Its runtime also exposes a deployment credential. That credential can modify a production workload.
The agent’s job description says “analytics.” Its effective access, however, says more.
This is where broad permissions and neglected service account security turn a bounded task into a wider exposure. Authentication establishes identity; authorization determines permitted actions.
We need identity provenance: who granted authority, through which role or integration, and for what purpose. Otherwise, access creep quietly becomes the default architecture.
The National Institute of Standards and Technology’s February 2026 concept paper identifies delegation and accountability as agent-identity challenges. Giving an agent an account is really only the beginning.
Put AI access controls where actions happen
We can start with identities that have the potential to export sensitive data, modify production, issue credentials, or cross environment boundaries. Include people, workloads, and agents.
For each, it’s important we establish an owner, approved task, permission scope, and expiration policy. This should have separate query permissions from export, write, and administrative capabilities.
Our AI access controls must enforce those boundaries. “Please don’t touch production” is optimistic at best, and won’t survive an audit.
The UK National Cyber Security Centre’s August 2026 advice recommends distinct agent identities, constrained credentials, monitoring, and emergency shutdown capabilities. It explicitly warns against relying on prompting alone. It also recommends urgency.
Prove that revocation works
We should consider running a controlled exercise against a representative workflow. Starting an approved session, initiating containment, and verifying when the target system rejects further activity.
We should check existing sessions, refresh mechanisms, delegated credentials, and running jobs. Recording what persists and who can stop it. Handling compromised credentials requires evidence beyond a successful deprovisioning notification.
Short-lived tokens help, but credential issuance also needs protection. NIST’s September 2026 token-security guidance addresses forgery, theft, and misuse.
We should be measuring from the containment decision to verified denial.
Give the next 90 days a deliverable
We don’t need to rebuild the entire identity estate this quarter. We need a bounded program with owners and testable results.
- Days 1–30: Select critical workflows, map effective access, and establish a containment baseline. Rank identity debt by what it exposes.
- Days 31–60: Remove unnecessary grants. Introduce just-in-time access for suitable elevated tasks, with documented exceptions for persistent workloads. Work toward zero standing privileges where operationally appropriate.
- Days 61–90: Test containment, emergency access, and recovery. Connect access automation to approved response playbooks. Confirm responders retain the authority they need when ordinary access is restricted.
Report exposure reduced, not tickets closed
Here’s where we should be tracking standing privileged access, ownership coverage, exception age, and verifying containment time. We should also include access delays and workload failures so improvement doesn’t conceal operational damage.
For security operations, the next step is practical: choose one consequential workflow and test whether we can stop its access.
If we can’t demonstrate that today, we’re well on the road to being ready for tomorrow.
Start here, ideally yesterday
The perfect (and free) starting point: grab the Trustle trial to uncover excessive permissions, evaluate temporary access workflows, and reduce standing privileges across supported environments, in as little as 30 minutes. Let’s turn the next 90 days into evidence of reduced exposure.
