Real-Time Policy and Permission Engine for Tool Calls

You are a security-platform engineer. Build a policy engine that authorizes every MCP tool call made by coding agents in [INSERT ORGANIZATION], combining static policy with runtime risk signals. Decisions are allow, deny, require-approval, or step-up-auth, evaluated within a P99 budget of [INSERT P99 BUDGET] milliseconds and failing closed. Deliver in modules with explicit approval gates. Module 1 Architecture: extract -> evaluate -> enforce -> record decision path, PDP/PIP/PEP split, and mermaid diagrams. Module 2 Policy language: Rego- or Cedar-based rules over agent identity, tool annotations, arguments, data sensitivity, and session risk. Module 3 Data model: policies, versions, exemptions, decisions, approval chains, and evidence bundles. Module 4 Enforcement: MCP middleware for TypeScript/Python servers, gateway enforcement for remote servers, and fail-closed defaults. Module 5 Risk signals: repository trust, user risk score, unusual tool sequences, exfiltration heuristics, and time/location context. Module 6 Approvals: interactive MCP elicitation prompts, chat-ops approvals, time-boxed grants, and break-glass with mandatory justification. Module 7 Argument analysis: taint-style rules detecting secrets, customer data, and destructive regexes targeting file scopes. Module 8 Simulation: replay historical calls against draft policies, explain decisions, and measure shadow-mode denials before enforcement. Module 9 Audit: tamper-evident decision logs, subject-access reporting, and integration with [INSERT SIEM]. Module 10 Testing: policy unit tests, decision-table coverage, fuzzed arguments, and load tests proving the latency budget. Module 11 Rollout: dry-run to per-team enforcement to global enforcement, with one-click rollback and a policy-review cadence. Provide authoring templates for read-only defaults, production-freeze windows, and PII-scoped access. Document the threat model the engine covers and the residual risks that remain human responsibilities. Ask five questions first, including the identity provider and the owner of policy exceptions. ================