MCP Iteration 4: production hardening and privileged actions

[patoperpetua]

Parent: #81
Depends on: #84

Goal

Harden the MCP integration for broader use and only then expose privileged PostKit actions such as sending email.

Scope

Security and authorization

• Review all MCP tools against least-privilege principles.
• Require explicit permission for every privileged operation.
• Ensure tenant isolation is enforced in the application layer.
• Add credential/token revocation handling where applicable.
• Add rate limiting/throttling appropriate for MCP and REST clients.
• Prevent secrets, provider credentials, rendered sensitive content and raw auth tokens from appearing in logs/errors.

Auditability

Record security-relevant actions with enough context to answer:

• who/what performed the action;
• authentication type/client identity;
• PostKit tenant;
• action/tool;
• template ID/version where applicable;
• recipient domain or privacy-safe recipient reference as appropriate;
• timestamp;
• outcome;
• correlation/request ID.

Privileged MCP tools

Evaluate and, if approved, add:

• postkit.send_email

Potential future operations should be evaluated separately rather than exposing generic mutation endpoints.

send_email must require an explicit high-privilege permission such as email:send / corresponding Entra scope or app role.

Safety controls for sending

Consider:

• environment restrictions so development agents cannot accidentally send production email;
• recipient allowlists in non-production environments;
• dry-run/preview option where useful;
• clear distinction between preview and actual send;
• idempotency where duplicate sends are a realistic risk;
• provider failure/retry behavior;
• audit event for every attempted send.

Operational readiness

• Add health/diagnostic coverage for the MCP endpoint.
• Confirm Azure Function scaling/cold-start behavior is acceptable.
• Measure real MCP request latency and memory usage before considering alternate hosting.
• Document when moving MCP to Azure Container Apps or another always-on host would actually be justified.

Acceptance criteria

• Privileged MCP actions cannot execute without the required authorization.
• Cross-tenant access tests exist and pass.
• MCP calls are observable and auditable without leaking secrets.
• Rate limiting/throttling is documented and tested.
• Non-production email sends cannot accidentally target unrestricted production recipients.
• postkit.send_email, if enabled, uses the same core send service as REST/API consumers.
• Azure Functions remain the default host unless measurements demonstrate a concrete limitation.
• A security review checklist is documented for adding future MCP tools.