--- title: Security description: Security considerations and best practices for the AIC MCP Server. component: build-with-ai page_id: build-with-ai:aic-mcp-server:security canonical_url: https://developer.pingidentity.com/build-with-ai/aic-mcp-server/security.html revdate: April 20, 2026 keywords: ["MCP", "security", "best practices", "AIC", "audit"] section_ids: security-layers: Security layers audit-and-traceability: Audit and traceability tracing-actions-to-the-mcp-server: Tracing actions to the MCP server identifying-mcp-traffic: Identifying MCP traffic best-practices: Best practices feedback-and-issues: Feedback and issues --- # Security The AIC MCP Server is built with a "secure by design" philosophy. This page describes the security layers and best practices to follow when using the server. ## Security layers The AIC MCP Server implements multiple security layers: * Secure credential storage Tokens stored in the OS keychain (macOS Keychain, Windows Credential Manager, Linux Secret Service) for local deployment, or ephemerally in the container filesystem for Docker. * No plain text secrets No sensitive information stored in configuration files. * OAuth 2.0 authentication PKCE flow for local deployment prevents authorization code interception. Device Code flow for containerized deployment. * User-based authentication All API calls are authenticated as the user who logged in, providing complete audit trails. * Input validation Built-in protections against path traversal and query injection attacks. * Tenant isolation Tokens are validated against the configured `AIC_BASE_URL` to prevent accidental cross-tenant operations. ## Audit and traceability Every API call made by the AIC MCP Server is authenticated with an OAuth 2.0 access token tied to the administrator who logged in. PingOne Advanced Identity Cloud logs all API activity against this authenticated identity, providing a complete audit trail. ### Tracing actions to the MCP server Because the AIC MCP Server requires administrator authentication via PKCE (or Device Code for Docker), every action is recorded in PingOne Advanced Identity Cloud audit logs under the authenticated user's identity. If an administrator needs to determine whether a change was made through the MCP server, they can use the following approach: 1. **Identify the user:** The AIC MCP Server authenticates using two registered OAuth 2.0 clients: * `AICMCPClient` - used for the initial user login (PKCE or Device Code flow) * `AICMCPExchangeClient` - used to obtain scoped tokens for each tool call via RFC 8693 token exchange All API requests carry an access token issued on behalf of the logged-in administrator. Each token exchange references the original user login, providing a complete chain from the tool call back to the authenticated identity. 2. **Query audit logs:** Use the PingOne Advanced Identity Cloud admin console or the AIC MCP Server logging tools to query audit logs filtered by: * The administrator's username * The time window of the suspected action * The `am-authentication` or other relevant log source Filtering the `am-authentication` log source for either of the client IDs above surfaces all MCP authentication activity. For example, ask your AI assistant: *"Show me all logs for user from 2 PM to 3 PM yesterday"* 3. **Correlate with the OAuth client:** API calls originating from the AIC MCP Server use the `AICMCPClient` or `AICMCPExchangeClient` client IDs. Look for these identifiers in the log entries to distinguish MCP server actions from direct admin console or API activity. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The AIC MCP Server's own logging tools can help with this investigation. Use prompts like *"Find all logs for transaction abc-123"* or *"Show me authentication events from the last hour"* to quickly locate relevant activity. | ### Identifying MCP traffic All requests from the AIC MCP Server include a `User-Agent` header in the form `aic-mcp-server/`. You can use this to filter access logs and isolate MCP-originated traffic from browser sessions, automated reconciliation jobs, and other API clients. ## Best practices | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | **Review all generated configuration** before promoting to production environments or those serving live identity and access requests. AI-driven operations can make mistakes. Treat AI-generated changes the same as any code review. | Follow these best practices when using the AIC MCP Server: 1. **Use trusted AI assistants.** Do not use the AIC MCP Server with untrusted MCP clients, agent code, or LLM inference. Depending on requests made to the server, tenant configuration or data can be returned. 2. **Review changes before promotion.** Configuration generated dynamically using LLM feedback can be represented dynamically back to agents and conversations. Always review before promoting to higher environments. ## Feedback and issues Report security concerns, bugs, or enhancement requests through the [GitHub issue tracker](https://github.com/pingidentity/aic-mcp-server/issues).