Automation Anywhere Agent Interoperability security and governance
- Updated: 2026/02/20
Security and governance are foundational pillars of Agent Interoperability inside Automation Anywhere. Our Model Context Protocol (MCP) implementation is designed with a security-by-design philosophy to ensure that sensitive data, automations, and enterprise assets are protected across Agent-to-Agent and Agent-to-Automations interactions.
Our security framework enforces strict trust boundaries, strong authentication, authorization, encryption, and full auditability, aligned with enterprise and industry security standards.
Zero-Trust security model
- Every interaction , tool discovery, invocation, or automation execution must be explicitly authenticated and authorized.
- Trust is never assumed based on network location, agent identity, or prior requests.
- Each request is evaluated independently with enforced security checks, ensuring that unauthorized access or lateral movement is not possible.
- All inbound traffic entering the MCP and Control Room boundary is validated at multiple layers, including authentication token validation and license verification before any processing is allowed.
Secure authentication and identity validation
- API key–based authentication is used to identify and authenticate MCP clients.
- Each inbound request validates:
- The API key
- The associated user identity
- The active security context
- Authentication is performed against the Automation Anywhere Control Room authentication system, ensuring centralized identity enforcement.
- Authentication is applied per request, not per session, eliminating reliance on long-lived implicit trust.
- Authentication tokens are validated over HTTPS connections only, ensuring secure transport during identity verification.
- License validation is enforced during authentication to confirm tenant entitlement before allowing MCP tool access or automation execution.
User security context and session isolation
- Every MCP call is executed within the security context of the authenticated user.
- Automation Anywhere MCP server does not execute actions with elevated or shared privileges.
- Automations triggered by third-party AI assistants run as the requesting
user, inheriting:
- That user’s permissions
- That user’s access restrictions
- Sessions are logically isolated, ensuring:
- No cross-user data leakage
- No shared execution context between different MCP clients or users
Role-Based Access Control (RBAC)
- MCP tool creation and management
- The creation, configuration, and management of MCP inbound tools (from the AI -> Agent connections page) is governed by RBAC.
- Only users with explicitly assigned roles can:
- Create MCP inbound tools
- Modify tool definitions
- Manage tool exposure to AI assistants
- Tool discovery and invocation
- Every tool discovery and invocation request is validated against the user’s assigned roles.
- Unauthorized users cannot discover or invoke tools, even if they are aware of tool identifiers.
- Automation execution using AI assistants
- When running automations through:
- A third-party AI assistant using the Process Reasoning Engine (PRE) (see Process Reasoning Engine and generative AI for details) , or
- The DiscoverAutomation tool
- Users can only access and execute automations that they are authorized for in the Control Room repository.
- RBAC policies defined in Control Room are strictly enforced during runtime.
- When running automations through:
Regional MCP service layer – runtime security and infrastructure protection
The MCP regional service layer acts as a strong execution boundary between external AI Assistants and the Automation Anywhere Control Room. It uses infrastructure, runtime, and API protection controls that follow cloud-native security best practices.
- Authentication tokens are validated over HTTPS before being accepted by the container boundary.
- License entitlement checks are performed before processing any tool invocation request.
- Per user rate limit and per tenant rate limit is enforced to prevent abuse, denial-of-service risks, and excessive consumption.
- Rate limits apply uniformly across MCP inbound tool calls to ensure fairness and protect shared infrastructure.
These controls ensure resilience, fair usage, and protection against automated abuse or malicious flooding attempts.
Secure communication and data protection
- TLS 1.2 encryption is used for:
- MCP client ↔ Automation Anywhere MCP server communication
- Automation Anywhere MCP server ↔ Automation Anywhere Control Room communication
- Encryption ensures:
- Data confidentiality
- Data integrity
- Protection against man-in-the-middle (MITM) attacks
- Sensitive payloads, credentials, and execution metadata are never transmitted in plain text.
- All authentication token validation occurs strictly over HTTPS-secured channels.
Public ingress security at Control Room level
The Control Room enforces strict public ingress controls to protect external-facing endpoints.
- A Web Application Firewall (WAF) is deployed at the public Control Room ingress layer to inspect and filter incoming traffic.
- The WAF provides protection against common web threats such as injection attacks, malicious payloads, and abnormal request patterns.
- All application pods run within private subnets that are fenced off from the public internet.
- Only the ingress layer is publicly accessible; back-end services are not directly exposed externally.
This network segmentation and ingress protection strategy establishes a strong external trust boundary and minimizes the attack surface.
Auditing, logging, and governance
- All MCP inbound tool calls are logged, including:
- User identity
- Tool invoked
- Timestamp
- Execution outcome
- Logs enable:
- End-to-end traceability of AI-initiated actions
- Compliance with regulatory and audit requirements
- Monitoring and anomaly detection
- Logging supports governance use cases such as:
- Security reviews
- Incident investigation
- Usage analysis and policy enforcement
Industry-Aligned security controls within Automation Anywhere MCP implementation
| Security Aspect | MCP Implementation |
| Zero Trust | Explicit authentication and authorization for every request |
| Authentication | API key–based + HTTPS token validation + License validation |
| Session Isolation | Per-user execution context, no shared sessions |
| Authorization | Multi-layer RBAC enforcement |
| Least Privilege | Automations run only with user-granted permissions |
| Rate Limiting | Per user and per tenant rate limit to prevent denial of service risk |
| Encryption | TLS 1.2 for all communication |
| Network Segmentation | WAF at ingress + pods in private subnets |
| Auditability | Full logging of MCP inbound tool calls |