Your AI agents need identity records just like your employees do. However, many security teams still track them in spreadsheets or, worse, don't track them at all. When an agent holds API keys to your production database, customer data warehouse, and cloud infrastructure, this is not acceptable.
This template provides a starting point for governing AI agents as machine identities with the operational discipline of ISO/IEC 42001 and the risk perspective of the NIST AI RMF. You'll establish ownership, lifecycle controls, and continuous risk assessment for every agent in your environment.
Purpose of This Template
Use this template to create identity records for autonomous AI agents that:
- Make decisions without human approval
- Hold access credentials to internal systems
- Process sensitive data
- Integrate with multiple services or APIs
- Operate across different security contexts
This is not for simple automation scripts or scheduled tasks. You're governing agents that exhibit behavior patterns similar to human users — they authenticate, make choices, and their actions have business consequences.
Prerequisites
Before deploying this template, ensure you have:
Organizational Prerequisites:
- An executive sponsor who can enforce agent registration (typically CISO or VP Engineering)
- A defined process for agent provisioning requests
- Integration with your existing IAM system or identity store
Technical Prerequisites:
- An inventory of existing AI agents (even partial — you'll iterate)
- Access to authentication logs showing agent activity
- The ability to tag or label agent identities in your directory
Framework Alignment:
- Familiarity with ISO/IEC 42001 clauses on AI system lifecycle management
- Understanding of NIST AI RMF's continuous risk management approach
If you're missing the technical prerequisites, start there. You can't govern what you can't see.
The Template
Copy this into your identity management system or governance documentation:
AI_Agent_Identity_Record:
# BASIC IDENTITY
agent_id: [Unique identifier - format: AI-AGENT-YYYY-NNN]
agent_name: [Human-readable name]
agent_type: [autonomous_decision_maker | data_processor | integration_orchestrator | security_scanner]
# OWNERSHIP & ACCOUNTABILITY (ISO/IEC 42001 Clause 5.1)
business_owner: [Name, email, department]
technical_owner: [Name, email, team]
escalation_contact: [On-call rotation or manager]
cost_center: [For access auditing and license tracking]
# LIFECYCLE STATUS
lifecycle_stage: [development | staging | production | deprecated | decommissioned]
deployment_date: [YYYY-MM-DD]
last_review_date: [YYYY-MM-DD]
next_review_date: [YYYY-MM-DD - default 90 days]
retirement_criteria: [Conditions that trigger decommissioning]
# ACCESS & PERMISSIONS
authentication_method: [API_key | service_account | OAuth | certificate]
credential_location: [Secret manager path or vault reference]
credential_rotation_schedule: [days]
last_rotation_date: [YYYY-MM-DD]
access_scope:
- system: [System name]
permission_level: [read | write | admin]
data_classification: [public | internal | confidential | restricted]
justification: [Why this access is required]
# RISK PROFILE (NIST AI RMF)
risk_tier: [critical | high | medium | low]
risk_factors:
- factor: "Holds credentials to production systems"
weight: [1-5]
- factor: "Processes customer PII"
weight: [1-5]
- factor: "Makes automated decisions affecting service availability"
weight: [1-5]
blast_radius: [Description of impact if agent is compromised]
compensating_controls: [List of mitigations - monitoring, rate limits, approval gates]
# MONITORING & OBSERVABILITY
logging_enabled: [yes | no]
log_retention_days: [number]
alert_thresholds:
- metric: "API calls per hour"
threshold: [number]
action: [alert | block | throttle]
- metric: "Failed authentication attempts"
threshold: [number]
action: [alert | block | throttle]
behavioral_baseline:
typical_call_volume: [requests per hour]
typical_data_volume: [MB per transaction]
expected_endpoints: [List of APIs/services]
expected_schedule: [24/7 | business_hours | batch_window]
# COMPLIANCE & AUDIT
regulatory_scope: [PCI_DSS | SOC_2 | HIPAA | none]
audit_frequency: [quarterly | annual]
last_audit_date: [YYYY-MM-DD]
audit_findings: [Link to findings document]
# CHANGE MANAGEMENT
change_approval_required: [yes | no]
change_notification_list: [Email distribution list]
rollback_procedure: [Link to runbook]
Customizing the Template
For Your Risk Appetite:
If your organization operates in a high-risk environment (financial services, healthcare), set next_review_date to 30 or 60 days instead of 90. If an agent processes restricted data, add a data_processing_agreement field linking to your DPA registry.
The risk_tier calculation should reflect your actual tolerance. Here's a starting formula:
- Critical: Agent holds admin access to production systems OR processes restricted data at scale OR makes decisions that directly affect customer transactions
- High: Agent holds write access to customer data OR integrates with 5+ internal systems OR operates without human review
- Medium: Agent holds read access to internal systems OR processes internal-only data OR has approval gates for sensitive actions
- Low: Agent operates in isolated environments OR processes only public data OR requires human confirmation for all actions
For Your IAM Architecture:
If you use a centralized identity provider (Okta, Azure AD, etc.), populate agent_id using your existing naming convention. If you manage service accounts separately, add a linked_service_account field to cross-reference.
The authentication_method should match your actual credential management. If you're using short-lived tokens, add token_lifetime_minutes and token_refresh_policy fields.
For Continuous Risk Management:
NIST AI RMF treats AI risk as continuous rather than static. Your behavioral_baseline section operationalizes this. During your first review cycle, establish actual baselines from logs. After 30 days, compare current behavior to baseline and update the record with any drift.
Add a risk_reassessment_triggers section listing events that require immediate review:
- Agent requests new permissions
- Authentication failures exceed threshold
- Behavioral anomaly detected
- Underlying model or codebase updated
- Regulatory requirements change
For ISO/IEC 42001 Alignment:
ISO/IEC 42001 requires operational discipline around AI system lifecycle management. Map your template fields to specific clauses:
business_ownerandtechnical_owner→ Clause 5.1 (Accountability)lifecycle_stageand review dates → Clause 8.2 (AI system lifecycle)monitoring_enabledand alert thresholds → Clause 8.3 (Performance monitoring)change_approval_required→ Clause 8.4 (Change management)
Validation Steps
Week 1: Pilot with 5 Critical Agents
Identify five agents that meet your "critical" risk tier criteria. Complete their identity records. Schedule a 30-minute review with each business owner to validate the access scope and blast radius fields.
Week 2: Establish Baseline Monitoring
Configure logging for your pilot agents. Run a query to establish actual call volume, data volume, and endpoint patterns. Update the behavioral_baseline section with real numbers.
Week 4: First Risk Review
Compare current agent behavior to your baselines. Document any deviations. If an agent's actual access exceeds what's documented in access_scope, that's your first finding — escalate it.
Month 3: Expand Coverage
Aim for 80% coverage of autonomous agents by month three. You won't find them all immediately — that's expected. Set a quarterly target to reduce the unknown population.
Ongoing: Enforce the Review Cycle
When next_review_date arrives, your IAM system should automatically notify the business owner. If they don't complete the review within 7 days, escalate to their manager. If they don't complete it within 14 days, disable the agent's credentials.
This enforcement mechanism transforms the template from documentation into governance.
