Chapter 10 · Operate
Security Model
The rules that keep this server safe in production: delegated identity, no standing credentials, a hardened gateway, redacted logs, and bounded responses. Read this before you deploy anything real.
🎯 What you'll be able to do
- Recite the non-negotiable security rules
- Trace where identity flows and where permissions are enforced
- Map each asset to its threat and mitigation
- Convert the server to a safe read-only deployment
Non-negotiable rules
For this type of MCP server
- Do not use Jira service accounts for user-specific data.
- Do not store Jira PATs.
- Do not store user refresh tokens in the MCP server.
- Do not log bearer tokens.
- Do not return raw upstream errors that may contain sensitive data.
- Do not use wildcard CORS in production.
- Do not expose direct app host access as the intended production path.
- Do not return unlimited search results.
Identity diagram
Loading diagram…
Threat model summary
| Asset | Threat | Mitigation |
|---|---|---|
| User Jira data | Cross-user access | Delegated bearer token per request; Jira enforces user permissions. |
| Atlassian OAuth client secret | Leakage | Stored in the Power Platform connector, not server code. |
| Gateway secret | Direct app bypass | Key Vault secret injected by APIM and checked by the app. |
| Public endpoint | Abuse | APIM rate limits, quotas, IP filtering, TLS. |
| Tokens in logs | Disclosure | Redacting logging filter. |
| Large Jira responses | Agent failure | Field projection and byte-budget trimming. |
| Container runtime | Privilege escalation | Non-root runtime user. |
| Source repository | Secret leakage | .env ignored and gitleaks in CI. |
Defense in depth
Notice that no single control is trusted alone. Even if APIM is misconfigured, the app still checks the gateway token; even if a log line is careless, the redaction filter catches the token. Layers mean one mistake isn't a breach.
Read-only mode
For a read-only deployment:
- Remove
write:jira-workfrom the connector scopes. - Remove the write tools:
jira_create_issue,jira_update_issue_summary,jira_add_comment,jira_transition_issue. - Keep the read tools:
jira_whoami,jira_search,jira_get_issue,jira_list_transitions,jira_get_projects. - Update documentation and tests to match.
Tip
Read-only is an excellent first production deployment: it delivers value (search, lookups, project lists) while removing any chance of the agent modifying data while you build confidence.
❓ Concept check
Someone proposes adding a jira_run_jql tool that executes any JQL with no result cap, “for power users.” Which two non-negotiable rules does this violate?
📌 Chapter summary
- No service accounts, no PATs, no stored refresh tokens, no token logging, no wildcard CORS, no unlimited search.
- Jira enforces user permissions; the gateway secret blocks direct app access.
- Read-only mode = drop write scopes and write tools, keep read tools.