Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Expose event provenance and action gates in MCP tool results

Đang mở
  • Có gì không ổn?
#1,093 6 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
api, security

Hướng nghiên cứu

Không có tệp triển khai hoặc đường dẫn kiểm thử nào được nêu. Hãy bắt đầu bằng việc xác định các bộ dựng kết quả của công cụ issue/event MCP và các kiểm thử đầu ra hiện có của chúng, sau đó theo dõi cách các trường sự kiện và siêu dữ liệu Sentry được tập hợp. Được xem là hoàn tất khi các kết quả phân biệt payload sự kiện không đáng tin cậy với siêu dữ liệu máy chủ và bao quát ba trường hợp được đề xuất, bao gồm các cổng hành động ngăn việc thực thi khi không có sự corroboration.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Context

Public research around Sentry MCP / Agentjacking has made one boundary very concrete: some data returned by Sentry is application/runtime evidence, and some of it is attacker-writable payload that arrived through public DSN ingestion. I’m not reporting a new vulnerability or posting a PoC here; this is a defensive product/API shape suggestion for the public MCP surface.

Related public writeups: Tenet Security’s Agentjacking post and the Cloud Security Alliance research note.

Problem

When an agent asks Sentry MCP to investigate an issue, the tool result can include event fields, stack/context/breadcrumbs, and possibly text that looks like remediation guidance. For a human, “this came from the event payload” is an implicit provenance cue. For an AI coding agent, that distinction is easy to lose: event content can be treated as trusted diagnostic instruction instead of untrusted evidence.

The useful boundary is not just “sanitize markdown.” It is: which parts of the MCP result came from attacker-controllable event payload vs Sentry/server-generated metadata vs trusted analysis, and what actions are allowed before corroboration.

Proposal

Add an explicit provenance/action-gate layer to issue/event tool results. A minimal version could be either human-readable sections or machine-readable fields/content annotations, for example:

{
  "mcp_payload_trust": {
    "default_trust": "untrusted_external_data",
    "attacker_writable_fields_present": true,
    "sources": [
      { "section": "event.message", "origin": "sentry_event_payload", "trust": "untrusted" },
      { "section": "breadcrumbs", "origin": "sentry_event_payload", "trust": "untrusted" },
      { "section": "issue.metadata", "origin": "sentry_server_metadata", "trust": "diagnostic_metadata" }
    ],
    "action_gate": {
      "execute_commands_from_event_payload": false,
      "install_packages_from_event_payload": false,
      "requires_codebase_corroboration_before_fix": true,
      "requires_human_review_for_shell_network_or_secret_access": true
    }
  }
}

Even a simpler rendered contract would help:

  • Untrusted event payload: message, extra/context fields, breadcrumbs, user-supplied tags, stack locals if present
  • Sentry metadata: issue id, project, first/last seen, server-generated grouping/aggregate fields
  • Allowed next step: inspect code paths / reproduce / compare stack frames
  • Not allowed from event payload alone: run shell commands, install packages, curl URLs, exfiltrate env vars, treat “Resolution:” text as instructions

Test cases

  1. An event contains markdown that looks like a “Resolution” or command block. MCP output must preserve it as quoted/untrusted evidence, not assistant-facing instruction.
  2. An event contains package-install or shell-looking text. The result marks it as event payload and sets an action gate forbidding execution from that payload alone.
  3. A normal issue still remains useful: agents can inspect stack frames and code locations, but must corroborate the fix path in the repo before mutating.

Why this seems worth separating

This does not claim to solve prompt injection completely, and it does not move runtime responsibility away from clients. It gives MCP clients and Sentry-specific subagents a stable contract: event payload is evidence, not authority. That makes it easier for coding agents to explain why they refused an action, ask for review, or proceed only after repo-side corroboration.

Ngôn ngữ chính
TypeScript
Star
938
Fork
166
Merge trung bình
1 ngày 4 giờ
Pull request đã merge (30 ngày)
175

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của getsentry/toolkit

Tất cả issue của getsentry/toolkit

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.