Agentic Access Management
A Comprehensive Approach to AI Identity and Access Security
Implementation Guidelines & Resources
Getting Started
Implementing the AI Access Management Framework requires a phased approach that balances immediate security improvements with long-term strategic goals. We recommend beginning with discovery and inventory (Pillar 1) to establish baseline visibility, followed by implementing ownership and accountability measures (Pillar 2) to establish governance foundations.
Cloud Platform Implementation Guides
Detailed implementation guides are available for major cloud platforms:
Azure Implementation Guide
Comprehensive guidance for implementing AI access management using Azure Active Directory, Key Vault, and Azure Security Center
AWS Implementation Guide
Step-by-step instructions leveraging IAM, Secrets Manager, and CloudTrail for AI access management
Google Cloud Implementation Guide
Best practices using Cloud Identity, Secret Manager, and Cloud Security Command Center
Azure AI Foundry
Background & Architecture
Overview
Azure AI Foundry is where language models are deployed.Projects are where AI agents are created and configured to utilize these deployed models.
Projects can be organized under two different architectural patterns: directly under an AI Foundry resource, or within a Hub that connects to AI Foundry resources.

Project Architecture Patterns
Key Architectural Difference: Identity vs Key-Based Access

One key difference between project types lies in their access approach:
AI Foundry Projects use managed identities and Role-based access controls (RBAC) for secure access to Azure resources, reducing reliance on stored secrets and providing direct Entra ID integration.
Hub Projects use key-based access through secrets stored in associated KeyVaults, requiring explicit secret management but enabling resource sharing across multiple projects.
AI Foundry Projects
Created directly under an AI Foundry resource with built-in identity management capabilities. These projects can utilize their associated managed identities for RBAC-based access to external Azure resources.
Hub Projects
Created within a Hub resource that provides shared infrastructure including Key Vault, StorageAccount, and compute resources. Hub projects can only access external resources using secrets stored in the associated Hub Key Vault. Hub projects are required for advanced features like prompt flows.
In addition, Hub projects are currently the only ones that can be set up with outbound network configuration to limit agent access to private resources.
Read more about Hub Project vs Foundry Project.
Permission Models
AI Foundry Project Permissions
IT Admin (Subscription Owner) assigns “Azure AI Account Owner” role on resource groups to managers
Azure AI Account Owner manages foundry infrastructure: deploys AI Foundry objects, deploys/decommissions AI models, applies guardrails (blocklist and content filtering) per deployed model, monitors model usage across all connected projects, and assigns “Azure AI Project Manager” roles
Azure AI Project Manager creates projects under the AI Foundry and assigns "Azure AI User" roles for specific projects
Azure AI User creates and configures agents at the project level
More information: Azure AI Foundry RBAC Setup
Hub Project Permissions
IT Admin (Owner) assigns managers with “Contributor” role for creating new hubs or “Azure AI Developer” role for hub configuration
Contributor manages hub infrastructure: compute resources, connected resources, and shared connections
Azure AI Developer creates Projects and shared resources (at Hub level) and creates agents and utilizes connected resources (at Project level)
More information: Hub Project RBAC Setup
Core Components
AI Foundry Resource
The central resource for model deployment and management:
- Model deployments: Models selected from catalog, multiple deployments of the same model are possible (assigned with different names)
 - Quota management: Per-deployment quota controls
 - Guardrails: Blocklist and content filtering configured per deployed model
 - Monitoring: Centralized usage monitoring for all connected projects
 
Hub Resource
Shared infrastructure platform, consisting of:
- One or more Projects
 - Key Vault for secret management
 - StorageAccount for data persistence
 - Compute resources (required for non-serverless operations like prompt flow)
 - Connected Resources
 
- Model (deployed at either Azure OpenAI or Azure AI Foundry)
 - External resources accessible via Access Keys (stored in Key Vault)
 
Network Configuration - In addition to inbound configuration, outbound can also be configured and limited to private networks and applied to all agents in related projects. See Network Configuration Guide.
Access Methods
API Key Authentication
Two API keys per AI Foundry resource with both keys visible in Azure Portal and only one visible in Foundry portal. Multiple API endpoints are available depending on specific API usage. Supports zero-downtime rotation workflows. See Key Rotation Guide.
RBAC Authentication
Role-based access leveraging Entra ID identities and the permission models outlined above.
External Tool Integration
Model Context Protocol (MCP)
Agents support MCP Tools requiring hostname or IP address specification. MCP servers can be deployed in public internet or Azure Virtual Networks. See MCP Integration Guide.
MCPs accessible through Azure Virtual Networks are reachable to Hub projects (requires configuring a proper outbound mode for the Hub).
Azure Functions
Functions can be invoked as agent tools through StorageAccount queue-based communication for input/output handling.
AI Search Service Integration
Core Functionality
The AI Search service provides vector database capabilities for contextual document embedding and retrieval:
- Document embedding: Converts records/documents from data sources into vector representations
 - Contextual proximity: Documents embedded in close vector space proximity indicate contextual similarity
 - Similarity search: Enables context-based retrieval of “most similar” items
 
Access Methods
- RBAC: Using built-in search roles
 - API Keys: Direct endpoint access using service keys
 
Data Source Integration
Cloud Data Sources:
- Blob Storage, Cosmos DB, SQL Database, Azure Table Storage
 - Authentication via managed identity or stored keys
 
External Data Sources:
- One of dozens of ADF connectors set as a Data source to an ADF pipeline
 - A Search service set as a Linked service in the ADF pipeline
 - The same Search service set as the pipeline’s output destination
 
More information: ADF Search Connector
Agent Integration: Foundry agents can connect directly to Search services for context-based search capabilities.
Additional External Data Access
Beyond Search service integration, agents support direct access to files in storage, SharePoint, Bing, and other a continuously expanding list of external data sources.
Azure AI Foundry
Framework Controls Implementation
Key Azure Resources to Inventory:
- Core resources: AI Foundry, AI Foundry Project, Hub Project, Hub, Search service
 - Identity components: System and User assigned identities for all resources
 - Credential stores: Key Vaults configured for Hub Projects and Hubs, or accessible to any other core resource.
 - Access mechanisms: API Keys (AI Foundry, Search service), RBAC principals
 - Tool identities: MCP Servers, Azure Functions, Search service data source keys
 
Azure Implementation:
- Apply resource tags for ownership on all AI Foundry resources (AI Foundry, Projects, Hubs, Search services)
 - Monitor human access through Azure Monitor resource logs and activity logs
 - Implement automated detection of unused identities using dedicated monitoring tools
 - Establish personnel change workflows that correlate ownership tags with HR systems for access transfer/revocation
 
Best Practices for Azure AI Foundry:
- Prefer identity-based access: Use AI Foundry-based projects over Hub projects when possible for RBAC capabilities
 - Minimize secrets: Configure connected resources and Search Service data sources with RBAC instead of API keys
 - Secure secret storage: Store ADF linked service secrets in Key Vaults, maintain consumer API keys in approved secret management systems
 - Enable OAuth: Use delegated OAuth for desktop applications instead of API keys where feasible
 
Implement key rotation: Leverage AI Foundry's dual API key system for zero-downtime rotation workflows
Resource Consumption Controls:
- Model quotas: Set per-deployment quotas in AI Foundry Management Center
 - Usage monitoring: Track token consumption through AI Foundry Management Center
 - Cost management: Monitor expenses via Azure Portal Cost Analysis
 - Agent resource limits: Control access through model deployment segregation
 
Data Exfiltration Risk Management:
- Assess risks for agents with sensitive data access and external connectivity
 - Implement appropriate data loss prevention controls for AI-specific scenarios
 
Vendor Classification Sources:
- ADF linked services catalog
 - Desktop applications using Azure AI Foundry access keys (usually done to configure LLM provider)
 - Connected external services and data sources
 
Geographic Controls:
- Azure AI Foundry models are Microsoft-managed and deployed in your specified region
 - Data residency aligns with existing Azure deployment regions
 
Audit Log Configuration:
- Activity logs: 90-day default retention, export to Log Analytics/Storage/Event Hubs for extended retention
 - Sign-in logs: 30-day Entra ID retention, forward to Log Analytics/SIEM for long-term storage
 - Resource logs: Enable diagnostic logging per service, configure destination-specific retention
 - Immutable storage: Implement for long-term audit log preservation in immutable storage accounts
 
Monitoring Requirements:
- Authentication pattern analysis using combined activity and sign-in logs
 - Resource consumption tracking through service-specific diagnostic logs
 - Behavioral anomaly detection via automated tooling
 - Policy violation detection and alerting
 
Implementation Notes:
- Risk-based prioritization should consider access patterns, data sensitivity, compliance status, and behavioral indicators
 - Establish KPIs for ownership assignment rates, credential rotation compliance, and policy coverage
 - Implement automated remediation workflows for common violations
 - Balance security controls with operational flexibility to support innovation
 
The Agentic Access Management Framework
The Agentic Access Management is a cross-industry collaboration
This framework is provided for informational purposes only. Implementation is at your own risk, and neither Sequoia nor Oasis accept any liability arising from the use of this framework.
© 2025 Oasis Security, Inc. All rights reserved. "AAM", "Oasis" and associated marks are trademarks of Oasis Security, Inc.