feat: Add index-level access control with pattern-based filtering

[smar-sean-sekora]

Summary

Implements index-level access control to restrict which OpenSearch indexes can be accessed through the MCP server. This
provides an additional security layer on top of OpenSearch's built-in permissions, allowing administrators to enforce access
policies at the MCP server level.

Motivation

Users need the ability to limit MCP server access to specific OpenSearch indexes without modifying underlying OpenSearch
security settings. This is particularly important for:

• Multi-tenant environments where different AI agents should access different index sets
• Production environments where sensitive indexes must be protected
• Development/testing scenarios where access to production data needs to be restricted

Changes

Core Implementation

• New Module: src/tools/index_filter.py - Pattern-based index filtering with support for:
  • Wildcard patterns (logs-*, test-?-index)
  • Regex patterns (regex:^logs-\d{4}-\d{2}$)
  • Allowed patterns (whitelist) and denied patterns (blacklist)
  • Priority-based validation (denied patterns checked first)

Integration

• Integrated validation into both stdio_server.py and streaming_server.py
• Added validate_index_access() calls to all tools with index parameters:
  • list_indices_tool, get_index_mapping_tool, search_index_tool
  • get_shards_tool, get_cluster_state_tool, get_segments_tool
  • get_index_info_tool, get_index_stats_tool
  • Dynamically generated tools (Count, Explain, Msearch)
• Special handling: list_indices without index parameter now uses allowed patterns to filter results via OpenSearch API

Configuration

• YAML Configuration:

  index_security:
    allowed_index_patterns:
      - "logs-*"
      - "metrics-*"
    denied_index_patterns:
      - "sensitive-*"
      - ".security*"
  

• Environment Variables:
  export OPENSEARCH_ALLOWED_INDEX_PATTERNS='["logs-", "metrics-"]'
  export OPENSEARCH_DENIED_INDEX_PATTERNS='["sensitive-*"]'

[cwperks]

Saw this in my Github inbox and it looked interesting. I just wanted to mention that there were similar access controls discussed with the extensions project where a request destined to be handled by an extension would receive an on-behalf-of token which is a short-lived access token for the authenticated user. The payload of the token would embed information about the authenticated user (sub claim) and the destination extension (aud claim). It was never implemented, but one of the ideas was to restrict how an extension could access the cluster.

So when evaluating perms it would have 2 gates for authz checks:

1. Can the extension access the indices
2. Can the authenticated user access the indices

If both gates passed then the request was permitted and executed.

I'm wondering if we should consider a solution similar to this here or directly put this into the MCP repo (caveat: I am not familiar with this repo)

[arjunkumargiri]

Thanks for raising this PR. I'm curious about the use case this addresses. Could you clarify when MCP server-level filtering would be preferred over OpenSearch's built-in security controls?

For example, if different agents require different index access, we could create separate MCP server instances, each with different OpenSearch roles/credentials mapped to each agent. This would leverage OpenSearch's native security model.

Is the goal here to handle scenarios where multiple clients share a single MCP server instance, or is there another use case I'm missing?

[rithin-pullela-aws]

@smar-sean-sekora, I agree with Arjun.

The solution you are proposing can be solved by configuring credentials with lower access level in OpenSearch's own Security plugin.