Trust & Privacy

Data handling, retention windows, and GDPR controls for JIRA MCP Remote.

Trust And Privacy

This service is hosted by the Innovation & Technology team at Spiris, running in Azure (Sweden region). It is designed to use the minimum data needed to authenticate users, execute Jira actions, and operate safely in a shared enterprise environment.

Authentication

Users sign in via Microsoft Entra ID (Azure AD) using OAuth. The service validates tokens issued by our Entra ID tenant and extracts the user's identity from the token claims. No passwords are handled by this service.

Azure AI Content Safety Prompt Shield

On supported remote deployments where MCP_PROMPT_SHIELD_FEATURE_ENABLED=true and Azure AI Content Safety is wired, Prompt Shield sends only returned Jira text segments to Azure AI Content Safety's shieldPrompt endpoint before the response is returned to the MCP client. The feature gate defaults off; when it is off, no Prompt Shield request is made and the Settings toggle is hidden. The screened scope includes Jira-returned error text, but it does not include outbound create/update/comment/search inputs or local scaffolding such as headings, browse URLs, PAT guidance, or fail-open warnings.

The normal Azure deployment path reuses the existing user-assigned managed identity plus the operator-configured Azure AI Content Safety resource scope. The remote app does not need a separate long-lived Prompt Shield API key in the normal Azure Container Apps happy path.

What Data Is Stored

  1. Sign-in and session state:
    • Temporary login/session details needed to complete browser sign-in and bind MCP sessions to the right user.
    • A browser CSRF token for cookie-authenticated web UI actions, bound to the current web session and retained only as transient state.
    • Per-session MCP client name (e.g., "claude-code", "Visual-Studio-Code") used for usage analytics.
    • This state is short-lived. By default it is kept in memory and lost on container restart. It can optionally be persisted via local file (MCP_TRANSIENT_STATE_BACKEND=file) or Azure Table Storage (MCP_TRANSIENT_STATE_BACKEND=table).
  2. Jira PAT enrollment state:
    • A user-scoped Jira personal access token (PAT) and whether it is currently valid.
    • PAT secrets are stored in an encrypted local file by default (MCP_PAT_STORAGE_BACKEND=local), or in Azure Key Vault when configured (MCP_PAT_STORAGE_BACKEND=keyvault). They are never stored in plaintext.
  3. User MCP profiles and preferences:
    • Profile id, profile name, selected tools, tool-result format preference, Prompt Shield opt-out state, and profile timestamps.
    • Persisted in a local JSON file by default (configurable via MCP_PROFILE_STORE_PATH).
  4. User activity metadata:
    • A per-user last-activity timestamp used to detect dormant accounts for cleanup.
    • Persisted in shared state when the inactive-user cleanup feature is enabled.
  5. Prompt Shield verdict cache:
    • Table-backed remote deployments cache HMAC-SHA256 keys for exact returned Jira text plus safe/unsafe verdicts and timestamps.
    • The cache does not store plaintext Jira text. Entries expire after 30 days and are versioned so policy/API changes can bypass old verdicts.
    • The HMAC key comes from stable deployment secret material. Rotating that secret intentionally makes old cache entries unreachable; they remain plaintext-free and expire by TTL while fresh Prompt Shield calls repopulate the cache.
  6. Upload staging data:
    • Temporary file content and metadata while processing attachment uploads.
    • Stored on the container filesystem (max 25 MB per file, expires after 15 minutes).
  7. Security audit events:
    • Structured audit records for authentication, PAT lifecycle, profile changes, policy decisions, and tool calls are emitted to stdout on every request.
    • Tool call events include a pseudonymous subject hash, profile kind, tool name, and MCP client name (generic product name, not user-identifying). Operational tracing logs use truncated (four-character prefix) subject identifiers rather than full values.
    • Each event includes a request correlation id to support incident investigation.
    • Container Apps automatically ingests stdout into Azure Log Analytics.
  8. Admin dashboard statistics:
    • The admin dashboard shows aggregated usage counts (top tools, top MCP clients, top profiles) queried from Azure Log Analytics over a 24-hour window.
    • User identifiers are shown truncated (first four characters only) in the active sessions table. Client names are generic product identifiers. Aggregated analytics use pseudonymous hashes.
    • Only accessible to designated admin users.

What Is Not Stored

  1. PAT values in plaintext at rest.
  2. PAT values in telemetry, audit events, or analytics.
  3. Raw usernames, emails, profile names, or tool arguments in audit events or operational logs.
  4. Arbitrary server-local file paths from clients for remote attachments (staged uploads are required).
  5. Jira issue content (this service proxies Jira requests; it is not an issue-content datastore).
  6. OpenTelemetry metrics and traces are not exported (OTLP export is not enabled).
  7. Returned Jira text that is screened by Prompt Shield is not written in plaintext by this service into the PAT store, profile store, audit logs, or Prompt Shield verdict cache.
  8. The normal Azure remote deployment path does not store a long-lived Prompt Shield API key or access token for runtime use; it relies on managed identity instead.

Retention

  1. OAuth/web transient state:
    • Login and OAuth transient states are retained for minutes, not hours.
    • Typical windows are 5 to 10 minutes depending on flow step.
    • Browser CSRF state for cookie-authenticated web actions is retained for up to 8 hours, or until the web session is no longer usable.
  2. MCP session state (owner mapping, bootstrap, client name):
    • Up to 8 hours since last activity, or until session deletion. Lost on restart only when MCP_TRANSIENT_STATE_BACKEND=memory.
  3. Upload staging:
    • Expires after 15 minutes. Successfully consumed uploads are deleted immediately after processing.
  4. PAT records:
    • Retained in the configured PAT store until the user rotates or deletes the PAT, or deletes account data.
  5. Custom profiles:
    • Retained in the configured profile store until the user deletes profiles or deletes account data.
  6. User activity metadata:
    • Retained until the account is deleted manually or by the inactive-account cleanup policy.
  7. Automatic inactive-account cleanup:
    • When enabled, the service checks accounts that have been inactive for a configurable window (90 days by default).
    • If the stored Jira PAT is missing or no longer validates against Jira, the service deletes stored PAT, profile, and related per-user server state.
    • If Jira is temporarily unavailable, cleanup is skipped until a later sweep rather than deleting data.
  8. Audit events / Log Analytics:
    • Retained according to the Azure Log Analytics workspace retention policy (default 30 days).
  9. Prompt Shield verdict cache:
    • Entries expire after 30 days and are removed by the same stale transient-state cleanup sweep used for table-backed session state.
  10. Prompt Shield request data:

GDPR

  1. Data minimization:
    • Only data needed for authentication, authorization, and operations is retained.
  2. User self-service deletion:
    • Users can delete account-scoped data from Settings (stored PAT + custom profiles) and sign out.
  3. PAT lifecycle controls:
    • Users can enroll, rotate, and delete their PAT.
  4. Automatic data hygiene:
    • Dormant accounts can be cleaned automatically when the configured inactivity window elapses and the stored Jira PAT no longer works.
  5. Data subject requests (access/erasure):
    • Fulfilled by deleting user-scoped PAT/profile/activity records from the configured stores, and applying retention controls in Log Analytics.