How to Kill Standing Access Without Killing Productivity in the Age of AI Agents
“I just need admin access so I can move fast.”
If you work in identity security, you’ve heard some version of that sentence more times than you care to count—whether it’s Salesforce, Snowflake, or “just a quick” production database change.
Underneath that simple request is the core tension of modern identity security:
Give people access so they can do their jobs.
Limit access so one compromised account doesn’t burn down the house.
Now layer AI agents on top of that—“ambitious employees that never sleep,” wired into Notion, Salesforce, GitHub, and your internal APIs—and the tension gets dialed up even further.
This post draws on a recent conversation with Kurt Hendle, Senior Director of Security Architecture (Chief Security Architect) at Teradata, to build a practical playbook: how to reduce standing access, move toward least privilege and just-in-time access, and keep AI agents under control—without turning security into a boat anchor.
Identity Is a Security Function, Not a Ticket Queue
In many organizations, identity security is still treated as an IT back office function:
IT owns the directory and SSO.
HR owns lifecycle data.
Help desk teams handle “add me to this group” tickets.
Product teams bolt on their own internal identity models.
Kurt’s view is blunt: that model is a risk.
Identity lives everywhere—enterprise IT, product environments, SaaS, cloud—but at the end of the day it’s a security control surface. It governs who can touch what, and with which level of privilege. If security-minded people aren’t deeply involved, over-permissioned identities become the default.
Thinking of identity as “the new perimeter” is actually misleading. Identity has always been one of the original perimeters. The difference now is that your old network boundaries are gone, and identity is the only reliable way to say “you’re in / you’re out” across SaaS, cloud, and AI-powered workflows.
If you’re serious about reducing identity risk, treat identity governance and access control as core parts of your security program, not just a service ticket pipeline.
The Real Attack Surface: Over-Permissioned Identities and Standing Access
Most breaches don’t start with some elegant zero-day. They start with over-permissioned identities and standing access.
The pattern is painfully familiar:
A user (or service account) gets more access than they strictly need because least privilege is hard and deadlines are real.
Their standing permissions accumulate over time: projects, moves, emergencies, “temporary” admin rights that never get revoked.
An attacker compromises one of those identities via phishing, password reuse, or token theft.
They enumerate what that identity can reach, move laterally, and daisy-chain their way to your crown jewels.
Least privilege sounds simple on paper: “You can do your job, and nothing more.” In practice, it’s expensive: you have to iterate, test, and tune permissions multiple times to get it right. Under pressure, “we’ll fix it later” wins over “let’s tighten this properly.”
The result is an environment full of standing admin rights and “Christmas tree” roles decorated with years of accumulated entitlements. That’s the identity attack surface you actually have today.
Joiners, Movers, Leavers: How Normal Business Creates Abnormal Risk
You don’t need anything exotic to create identity risk. Normal business operations are enough.
Think about joiners, movers, and leavers at scale:
People join with baseline access for their function.
They move teams, pick up project-specific permissions, temp admin roles, emergency exceptions.
They leave—but their access doesn’t always leave with them, or not completely.
At a large enterprise, you might have:
Employees rotating between departments every 12–18 months.
Contractors onboarded and offboarded on short notice.
Temps filling gaps during strikes or seasonal surges (like nurses or frontline staff in healthcare).
Each transition leaves a trail of entitlements behind. Trying to manually right-size all of that is effectively impossible once you go beyond a handful of employees.
This is where data and automation have to take over:
Use audit logs and access logs to see what’s actually used versus what’s assigned.
Identify unused or rarely used entitlements at the identity, group, and role level.
Use that usage picture to drive role mining and automatic right-sizing—rather than guessing.
If you’re not continuously comparing assigned vs. used access, you’re blind to the real shape of your standing privileges.
Compliance vs. Real Identity Security
Compliance frameworks finally forced many organizations to take user access reviews seriously. Quarterly or annual certifications are now table stakes.
But as Kurt puts it, compliance-driven security is minimum viable security. It proves you’ve done the least required to pass an audit—not that you’ve meaningfully reduced identity risk.
The limitations are obvious:
Quarterly reviews are snapshots. Attackers don’t schedule their campaigns for the week after your review.
Reviews are often treated as a checkbox exercise. Managers bulk-approve access they don’t fully understand.
Risky entitlements can sit in the environment for months between cycles.
For low-risk systems, periodic reviews may be acceptable. For high-risk environments—where sensitive customer data or regulated workloads live—you need to move toward continuous identity governance:
Automate entitlement recertification for low-risk, low-impact permissions.
Continuously flag anomalous access patterns and unused high-privilege entitlements.
Prioritize human attention on the riskiest identities and roles.
Compliance should be a side-effect of a strong identity security program, not its primary driver.
From RBAC to Just-In-Time: A Practical Identity Control Model
So what does a realistic identity security model look like?
Kurt’s answer is pragmatic: it’s less about a rigid framework, more about a sensible progression.
1. Start with RBAC, Mature into ABAC
In a greenfield or redesign:
Use RBAC (Role-Based Access Control) to define core job functions:
Map personas (e.g., “Sales Rep”, “Customer Support”, “DevOps Engineer”) to baseline permissions.
Use groups and roles to avoid direct entitlement assignment to individual users wherever possible.
Add ABAC (Attribute-Based Access Control) where it makes sense:
Department, region, environment (prod vs dev), risk level, customer segment.
Example: “Support Engineer in EU, working on non-production environments.”
RBAC and ABAC are not magic, but they give you structure. They reduce the chaos of one-off exceptions and direct grants.
2. Move Toward Just-in-Time and Zero Standing Access
The endgame is clear: zero standing access for anything sensitive, and just-in-time access for risky operations.
In a JIT model:
Identities do not hold permanent high-privilege roles.
When a user (or agent) needs elevated access:
They request it with a justification.
The request is evaluated based on risk, context, and policy.
If approved, the privilege is granted for a bounded time and then automatically revoked.
Historically, JIT access has been hard to implement because we tried to run it with humans. If you need a small army of identity admins to approve every single JIT request, you’ve just moved the bottleneck.
This is where automation and AI actually earn their keep:
Auto-approve low-risk, low-impact requests that match known patterns.
Require human review only for high-risk actions (e.g., production database writes, key management).
Enforce strict expiry and revocation, tied directly to workflow completion where possible.
You won’t get to 100% zero standing access overnight—and that’s okay. The trick is to aim for progress, not perfection, and keep shrinking the standing privilege footprint release by release.
AI Agents as First-Class Identities (Not Shadow Super-Users)
AI agents are where identity security gets weird—and urgent.
Imagine:
You build an automation agent that can read from Notion, query Salesforce, and update tickets.
You share that agent with another user who doesn’t have direct access to those systems.
Through the agent, they can now indirectly query and act on that data.
From an attacker’s perspective, that agent is a high-value identity with a fat permission set and 24/7 availability.
The fix is not to ban agents. It’s to treat agents like service accounts:
Give each AI agent its own unique identity (app registration, service account, workload identity).
Scope its permissions tightly to the specific tasks it needs to perform.
Log and monitor its activity like you would any other high-privilege non-human identity.
Prohibit agents from reusing human identities or piggybacking on human tokens whenever possible.
There’s another twist: LLMs and agentic AI are non-deterministic. The same input can yield different outputs. That’s fine when you’re drafting marketing copy. It’s less fine when an agent is touching production systems.
That’s why emerging guardrails frameworks matter:
Move critical constraints out of system prompts and into policy:
Which actions are allowed.
On which resources.
Under what conditions.
Wrap agents in workflows that enforce those policies:
“This agent can only read from Salesforce objects A/B/C.”
“This agent can never execute destructive operations.”
“Requests above a certain risk threshold require human review.”
In other words: don’t let “AI magic” bypass the identity and access control discipline you’ve spent years building.
Identity as a Business Enabler, Not a Boat Anchor
Security teams live with a constant fear: becoming the boat anchor that slows the organization down.
Kurt’s approach is to explicitly balance risk appetite and innovation:
For high-risk systems (crown-jewel data, regulated workloads), slow down where necessary:
Design the right controls.
Enforce JIT access.
Require strong approvals and auditing.
For low-risk or sandbox environments:
Allow faster experimentation.
Use fabricated or non-sensitive data.
Give teams room to iterate on new tools and agents.
The key is explaining this in business terms, not just security jargon.
When you’re in front of a CFO or CEO, the question is rarely “Are we secure?” It’s:
“Why should we invest in identity security and just-in-time access instead of shipping more features?”
To answer that, identity teams need to show:
Fewer standing admin accounts → lower blast radius.
Faster onboarding and offboarding → less downtime and risk.
Safer, governed AI usage → ability to embrace AI without ending up on the front page.
Identity security is a cost center only if you fail to connect it to uptime, productivity, and risk reduction in language the business understands.
A Practical Identity Security Checklist
If you’re looking to turn all of this into action, here’s a condensed checklist:
Clarify ownership. Make identity a joint initiative between security, IT, HR, and product—with clear security leadership.
Map your identity surface. Humans, contractors, service accounts, workloads, AI agents, and the key systems they touch.
Clean up roles and attributes. Use RBAC and ABAC to reduce direct entitlements and role sprawl.
Analyze usage. Continuously compare assigned vs. used access; target unused high-privilege entitlements first.
Introduce JIT access where it matters most. Start with privileged operations and crown-jewel systems.
Make AI agents first-class citizens in your identity model. Unique identities, narrow scopes, guardrails, and monitoring.
Report in business terms. Track metrics like time to provision/deprovision, reduction in standing admin accounts, and access-related incidents.
Are Your Identities Ready for Machine-Speed Risk?
Attackers are already operating at machine speed. AI agents are starting to do the same on the “legitimate” side of the house.
The question is simple:
If an attacker landed on your most over-permissioned identity—or your least-constrained AI agent—today, how far could they get before you noticed?
If that question makes you uncomfortable, that’s not a failure. It’s a roadmap.
If you want to go deeper, watch the full conversation with Teradata’s Chief Security Architect, Kurt Hendle, and steal what makes sense for your own identity security program. Then start shrinking your standing access footprint—without killing your organization’s ability to ship, experiment, and embrace AI.
