Three months ago, a security engineer asked me: "Do I need to treat our code generation bot the same way I treat service accounts?" Last month, a compliance manager wanted to know if AI agents count toward their privileged access review scope. Yesterday, someone asked if their customer support chatbot needs MFA.
These questions are coming from teams who've suddenly realized they're running dozens of autonomous systems with credentials, permissions, and the ability to take action without human approval. The identity management playbook you use for employees and service accounts doesn't quite fit. Here's what we're telling people.
What Counts as an "AI Agent"?
If it makes decisions based on context rather than following a fixed script, it's an agent. Your Jenkins pipeline that runs tests on every commit? That's automation. Your AI assistant that reads Slack messages, decides which ones need responses, drafts replies, and posts them? That's an agent.
The distinction matters because agents have autonomy. They interpret input, choose actions, and adapt behavior. That means you can't predict every action they'll take by reading their configuration file.
For inventory purposes, look for systems that:
- Accept natural language input or unstructured data
- Make choices between multiple possible actions
- Learn or adapt their responses over time
- Can chain together multiple operations to complete a task
Do I Need to Track All AI Tools Separately?
Yes, but you can tier them by risk. The three-category model helps: agentic chatbots, local agents, and production agents.
Agentic chatbots run in sandboxed environments, typically with read-only access. Your internal documentation assistant that answers questions about your codebase but can't modify anything? Low risk. Track it, document what data it can read, but it's not your priority.
Local agents run on individual machines with that user's permissions. The coding assistant in your developers' IDEs can read and write code, but only within that developer's workspace. Medium risk. If compromised, the blast radius is one user's access scope.
Production agents have direct access to production systems and can take automated actions. Your agent that monitors support tickets, queries customer databases, and updates account settings? High risk. These need the same scrutiny you'd give a service account with production database access.
What Permissions Should I Give AI Agents?
Start with the access-times-autonomy model. An agent's risk isn't just what it can access, it's what it can access multiplied by how independently it operates.
For high-autonomy production agents, apply the same controls you use for privileged service accounts:
- Dedicated credentials that aren't shared with humans or other systems
- Least-privilege access scoped to specific resources
- Activity logging that captures every action with enough detail to reconstruct what happened
- Regular access reviews (quarterly at minimum)
For chatbots with broad read access but no write permissions, you can relax some controls. But don't skip logging. You need to know what data they're exposing, even if they can't modify anything.
Here's a specific example: If your agent needs to query your customer database, don't give it a SELECT * permission on the entire database. Create a view with only the fields it needs, grant access to that view, and log every query. When someone asks "did the AI leak PII?", you'll have an audit trail.
Do AI Agents Need MFA?
Agents can't do MFA in the traditional sense, but you can require human approval for sensitive actions. Think of it as conditional autonomy.
For production agents performing routine tasks, use API keys or service credentials with IP restrictions and short rotation periods. For agents that perform sensitive operations (modifying access controls, processing financial transactions, accessing PII), require human-in-the-loop approval before execution.
Implementation-wise, this looks like:
- Agent identifies that an action requires approval
- Agent sends request to approval queue with context
- Human reviews and approves/rejects
- Agent proceeds or halts based on decision
Some teams implement this as a Slack workflow. Others build it into their ticketing system. The mechanism matters less than having the control.
Addressing the "It's Just a Chatbot" Argument
Ask three questions:
- What credentials does it use?
- What can it read or modify?
- If it behaved maliciously tomorrow, what's the worst thing that could happen?
The answers usually change the conversation. That "harmless chatbot" might be using someone's personal API key with admin access. It might be able to read your entire codebase, including hardcoded secrets. It might have write access to your knowledge base that serves external customers.
Document the blast radius in concrete terms. "This agent can read 400,000 customer records including email addresses and purchase history" is more convincing than "this could be a compliance issue."
Where Does This Fit in Our Compliance Scope?
If you're subject to SOC 2 Type II, AI agents with production access fall under your access control requirements. You need to demonstrate that you're tracking who (or what) has access to sensitive systems, reviewing that access regularly, and logging activity.
For PCI DSS v4.0.1, any agent that can access cardholder data needs to be part of your Requirement 7 (restrict access to cardholder data) and Requirement 8 (identify and authenticate access) controls. That means unique credentials, access reviews, and activity logs.
ISO 27001:2022 requires you to manage all identities with access to information assets. AI agents count. Include them in your asset inventory (Annex A 5.9) and access control procedures (Annex A 5.18).
Getting Control of Deployed Agents
Start with inventory. Spend a week documenting every AI agent in production:
- What it does
- What credentials it uses
- What systems it can access
- Who owns it
- When it was deployed
Then tier them by risk using the access-times-autonomy model. Focus your first month on the high-risk production agents: rotate their credentials, implement logging, and document their access scope.
For medium-risk local agents, standardize how developers provision and manage them. Create a template or approval workflow.
For low-risk chatbots, at minimum document what data they can access and confirm they're using dedicated credentials, not someone's personal API key.
Next Steps
Your identity governance tooling needs to track non-human identities. If your current IAM system only handles employees and contractors, you'll need to extend it or add tooling that can manage service accounts, API keys, and agent credentials in one place.
The goal isn't to block AI adoption. It's to ensure that when you deploy an agent with production access, you know what it can do, you're logging what it does, and you can revoke its access when needed. Same principles you apply to privileged human users, adapted for systems that make autonomous decisions.
