MCP Attribute-Based Access Control Policy | MuleSoft Documentation
# MCP Attribute-Based Access Control Policy
**Policy Name** | MCP Attribute-Based Access Control  
---|---  
Controls access to tools, resources, and prompts based on user information such as Tiers, IP, Headers, or Claims  
**First Flex Gateway version available**  
**Returned Status Codes** | 400 - Invalid token  
This policy supports Model Context Protocol (MCP) version 2025-06-18 and earlier. To learn more about MCP, see MCP Specification.   
---  
## Summary
The MCP Attribute-Based Access Control policy controls access to server tools, resources, and prompts based on user information such as Tiers, IP, Headers, or Claims. Use the Cedar policy language to define access rules.
This policy requires that another authentication policy be applied before the MCP Attribute-Based Access Control policy. For detailed guidance, see Writing Cedar Rules.
## Configuring Policy Parameters
### Flex Gateway Local Mode
The MCP Attribute-Based Access Control policy is not supported in Local Mode.
### Managed Flex Gateway and Flex Gateway Connected Mode
When you apply the policy to your API instance from the UI, the following parameters are displayed:
Element | Description  
---|---  
Rules to control access to tools, resources, and prompts written in the Cedar policy language.  
Cedar Expression |  Cedar expression defining the access rule. For example: `permit(principal,action == Action::"tools/call` or `resource == Tool::"calculator");`. To learn more about the Cedar bindings provided by the requests, see Writing Cedar Rules.  
Authentication Type |  Type of authentication used by the authentication policy applied before this policy.  
## Writing Cedar Rules
You must apply either an included authentication policy or a custom authentication policy before the MCP Attribute-Based Access Control policy.
### Included Authentication Policies
The authentication policy you apply affects the available Cedar `principal` bindings:
  * Multiple policies can validate Client ID:
    * Client ID Enforcement Policy
    * Rate Limiting: SLA-Based Policy
    * OAuth 2.0 Token Introspection Policy (If Client ID enforcement is configured)
    * OpenID Connect OAuth 2.0 Token Enforcement Policy (If Client ID enforcement is configured)
    * JWT Validation Policy (If Client ID enforcement is configured)
Policies validating Client ID provide these Cedar bindings:
    * `principal.client_name`: Name of the contract’s client application
    * `principal.principal`: ID of the contract’s client application
    * `principal.properties.slaId`: SLA ID assigned to the contract
  * JWT Validation Policy:
    * `principal.properties.claims.<claimName>`: All claims provided by the JWT
  * Multiple policies validate basic authentication credentials:
    * Basic Authentication: Simple Policy
    * Basic Authentication: LDAP Policy
Policies validating basic authentication credentials provide these Cedar bindings:
    * `principal.principal`: Username passed as basic auth user


### Custom Authentication Policies
For custom authentication policies, the custom policy must authenticate by using the `Authentication` injectable. To configure the `Authentication` injectable, see Accessing Request Authentication Information.
For the Rust `AuthenticationData` struct:
```
pub struct AuthenticationData {
  pub principal: Option<String>,
  pub client_id: Option<String>,
  pub client_name: Option<String>,
  pub properties: Value,
}
```

The `AuthenticationData` parameters map to these Cedar bindings:
  * `principal`: `principal.principal`
  * `client_name`: `principal.client_name`
  * `properties`: `principal.properties.*`