GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — feat: Add structured audit logging for MCP feature server · Issue #6452 · feast-dev/feast

feat: Add structured audit logging for MCP feature server #6452

New issue
Copy link
New issue
Copy link
Closed
#6456
Closed
feat: Add structured audit logging for MCP feature server#6452
#6456
Copy link
Labels
kind/featureNew feature or requestNew feature or request

Description

@patelchaitany
patelchaitany
opened on May 29, 2026
Issue body actions

Is your feature request related to a problem? Please describe.

Feast can expose the Python feature server as an MCP server (feature_server.type: mcp, mcp_enabled: true, endpoint /mcp) via fastapi_mcp. Operators and platform teams need a clear audit trail for agent/MCP access: who invoked which tool, what resource was accessed, whether authentication and authorization succeeded or failed, and a correlation ID that links MCP calls to internal REST requests.

Today, MCP integration only logs startup/errors (sdk/python/feast/infra/mcp_servers/mcp_server.py). That is not enough for security and operations use cases:

Mechanism What it does Gap for MCP audit
feature_logging Logs served feature values to the offline store Not a security audit log; not wired on the Python FastAPI MCP server
Uvicorn access logs HTTP path/status (off by default) No principal, no MCP tool name
RBAC logs Unstructured permission messages in app logs No MCP correlation; often DEBUG-only for allows

With auth.type: no_auth: MCP tool calls are effectively anonymous — no principal in logs.

With auth.type: oidc / kubernetes: RBAC applies on secured REST routes when the MCP client forwards Authorization (default in fastapi_mcp), but there is still no structured audit stream for MCP tools/call, successful reads, or request correlation. The /mcp transport itself is not audited.

Registry MCP (registry.mcp.enabled: true) has the same gap.

Describe the solution you'd like

Add structured audit logging (JSONL) for the Python MCP feature server, separate from feature_logging:

  1. Config under feature_server (e.g. audit_logging.enabled, sink, file_path, require_auth_for_mcp, log_successful_reads).
  2. Audit events with stable schema: event_type, UTC timestamp, request_id, principal, source (IP, transport), action (MCP tool / HTTP path), resource, outcome, duration_ms.
  3. Two emission layers:
    • MCP middleware on /mcp (mcp.tools.call, session events).
    • REST + RBAC hooks (authn.*, authz.decision, http.request) on secured endpoints.
  4. Header propagation via FastApiMCP(headers=[...]) so MCP and REST events share request_id (and optionally tool name).
  5. No sensitive payloads in audit logs (no tokens, entity rows, or feature values).

Optional follow-ups: registry MCP parity, OTEL sink, operator CRD fields.

Example config:

feature_server:
  type: mcp
  mcp_enabled: true
  audit_logging:
    enabled: true
    sink: stdout

Example event (JSONL):

{
  "event_type": "mcp.tools.call",
  "timestamp": "2026-05-28T12:00:00.000Z",
  "request_id": "…",
  "principal": {
    "username": "[email protected]",
    "roles": ["feast-reader", "ml-engineer"],
    "auth_type": "oidc"
  },
  "source": { "ip": "10.0.0.1", "transport": "mcp-http" },
  "action": { "mcp_tool": "get_online_features", "path": "/get-online-features" },
  "resource": { "type": "feature_service", "name": "driver_activity_v1", "actions": ["READ_ONLINE"] },
  "outcome": "success",
  "duration_ms": 42
}

Activity

  1. patelchaitany
    added
    kind/featureNew feature or requestNew feature or request
    on May 29, 2026
  2. HarperZ9 commented on Jun 28, 2026

    @HarperZ9
    HarperZ9
    on Jun 28, 2026
    More actions

    This audit stream becomes much more useful if each mcp.tools.call event is treated as a compact execution receipt, not only as an access log row.

    I would add a few fields to the proposed schema:

    • decision_id: stable join key shared by MCP middleware, RBAC decision, downstream REST request, and outcome event
    • policy_ref / policy_digest: the ruleset or RBAC snapshot that allowed, denied, or required approval
    • resource_digest: digest of the feature service/view identity and request shape, without feature values or entity rows
    • outcome_state: success | denied | error | timeout | redacted | unverifiable
    • prev_event_hash: optional per-session hash chain for tamper-evident export

    Two fixture cases would catch most regressions:

    1. OIDC principal calls get_online_features successfully: MCP event, authz decision, REST request, and outcome all share decision_id; no feature values are logged.
    2. Anonymous or unauthorized MCP call: denial event is emitted with principal/auth context, policy reference, and no downstream feature-read event.

    That keeps the audit trail useful for security review without turning it into a second feature log or leaking the data Feast is serving.

  3. ntkathole
    closed this as completedin #6456on Sep 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureNew feature or requestNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.