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_URLto 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:
-
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 exchangeAll 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.
-
-
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-authenticationor other relevant log sourceFiltering the
am-authenticationlog 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 admin@example.com from 2 PM to 3 PM yesterday"
-
-
Correlate with the OAuth client: API calls originating from the AIC MCP Server use the
AICMCPClientorAICMCPExchangeClientclient 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. |
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:
-
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.
-
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.