AI Agent Inventory: A Security Engineer's Field Guide

You can't secure what you can't see. That's the fundamental problem your security team faces with AI agents right now.

According to MIND research, AI agents have slipped away from security oversight. They're making API calls, accessing databases, executing code, and moving data, often without anyone in security knowing they exist. This guide provides a practical framework to build visibility into these systems before they become your next incident.

Scope - What This Guide Covers

This guide focuses on AI agents operating within your infrastructure: code generation assistants, automated testing tools, chatbots with backend access, and workflow automation systems. We're addressing agents that can read, write, or modify data, not passive analytics tools.

You'll find specific steps to inventory these agents, classify their access patterns, and establish baseline controls. This isn't about blocking AI adoption. It's about ensuring you know what's running in your environment.

Key Concepts and Definitions

AI Agent: Any autonomous or semi-autonomous system that uses machine learning models to make decisions, take actions, or access resources without direct human intervention for each operation.

Agent Scope: The combination of data sources an agent can access, actions it can perform, and systems it can modify. This differs from traditional application scope because agents often have dynamic, context-dependent permissions.

Shadow AI: AI agents deployed by business units or development teams without security review, similar to shadow IT but with active decision-making capabilities.

Agent Attestation: A documented record of what an agent does, what it accesses, and who authorized its deployment. Think of it as a certificate of analysis for each agent.

Requirements Breakdown

Inventory Requirements

Your first step is knowing what exists. Build an inventory that captures:

• Agent identity: Name, version, vendor (if third-party)
• Deployment context: Which team deployed it, when, and why
• Access scope: What APIs, databases, file systems, or external services it touches
• Authentication method: Service accounts, API keys, OAuth tokens, or embedded credentials
• Data classification: What sensitivity levels it processes (public, internal, confidential, restricted)

Control Requirements

Map each agent to your existing control framework:

For PCI DSS v4.0.1 environments, agents that access cardholder data fall under Requirement 6.4.3 (script security) and Requirement 8.2.1 (authentication for non-consumer users). Treat agent service accounts like any other system account.

For SOC 2 Type II, agents represent automated processing that must be included in your system description (CC6.1) and change management procedures (CC8.1).

For ISO/IEC 27001:2022, agents are information processing facilities under Annex A 8.1, requiring asset management and acceptable use policies.

Monitoring Requirements

Establish logging for:

• Agent authentication events
• Data access patterns (what the agent reads/writes)
• External API calls the agent makes
• Configuration changes to the agent itself
• Failed operations or error states

Implementation Guidance

Phase 1: Discovery (Week 1-2)

Start with your development teams. Ask three questions:

1. What AI tools are you using in your daily work?
2. Which ones have access to production systems or customer data?
3. Where are the API keys or credentials stored?

Survey your API gateway logs. Look for user-agent strings containing "bot", "agent", "gpt", or vendor names like "anthropic", "openai", "cohere". Filter for service accounts making repetitive calls.

Check your cloud provider's IAM audit logs. Service accounts created in the last 12 months with names like "ai-assistant" or "copilot-prod" are good candidates.

Phase 2: Classification (Week 3)

Build a simple risk matrix:

High Risk: Agents with write access to production databases, ability to execute code, or access to credentials/secrets
Medium Risk: Agents with read access to customer data or internal systems
Low Risk: Agents limited to public data or sandboxed environments

Don't try to block high-risk agents immediately. Document them first.

Phase 3: Baseline Controls (Week 4-6)

For each agent, implement:

Authentication hardening: Rotate any embedded API keys to short-lived tokens. If the agent uses a service account, enable MFA where possible (yes, even for service accounts; use certificate-based auth).

Least privilege: Trim permissions to exactly what the agent needs. If it only reads from three database tables, don't give it database-wide SELECT.

Audit trails: Ensure every agent action writes to your SIEM. Tag these logs distinctly so you can filter agent activity from human activity.

Kill switch: Document how to disable each agent quickly. This might be revoking an API key, disabling a service account, or updating a feature flag.

Phase 4: Ongoing Governance (Week 7+)

Add agent review to your existing change management process. When a team wants to deploy a new agent:

1. They complete an agent attestation form (who, what, why, what data)
2. Security reviews the access scope
3. The agent gets a unique identifier in your asset inventory
4. Monitoring rules get configured before deployment

Run quarterly agent audits. Compare your inventory against actual API usage. Decommission agents that haven't been used in 90 days.

Common Pitfalls

Pitfall 1: Treating agents like users. Agents don't have the same behavior patterns as humans. They make hundreds of API calls per minute, access data at odd hours, and follow deterministic patterns. Your anomaly detection rules need separate baselines.

Pitfall 2: Ignoring embedded agents. That GitHub Copilot instance running in every developer's IDE? It's accessing your codebase and potentially sending snippets to external APIs. Include it in your inventory even if it's "just a text editor plugin."

Pitfall 3: Assuming vendors handle security. Third-party AI services are responsible for their infrastructure, not for how you configure access in your environment. You still own the API key management and data classification decisions.

Pitfall 4: Blocking instead of governing. Developers will route around blanket blocks. You'll end up with more shadow AI, not less. Focus on visibility and reasonable controls first.

Pitfall 5: Static inventories. Agents change faster than traditional applications. A monthly inventory review is too slow. Build automated discovery that runs weekly.

Quick Reference Table

Control Area	What to Check	Frequency	Owner
Agent inventory	Compare documented agents vs. API gateway logs	Weekly	Security Ops
Access scope	Review IAM permissions for agent service accounts	Monthly	Identity team
Credential rotation	Rotate API keys and service account credentials	90 days	DevOps
Audit log review	Check for failed auth, unusual access patterns	Daily	SOC
Agent attestation	Verify documentation matches actual deployment	Quarterly	Security + Dev leads
Decommissioning	Remove unused agents and revoke credentials	Quarterly	Asset management
Incident response	Test agent kill switch procedures	Semi-annually	IR team

Start with inventory. You can't build controls until you know what you're controlling. Pick one team, one application, or one environment and map every AI agent touching it. Then expand from there.