Explainable runtime risk control for APIs

Turn runtime signals into explainable risk decisions.

RisCoPlane observes API behavior, activates named hazards, evaluates risk across configured dimensions, and explains mitigation decisions by connecting policy actions to evidence, thresholds, and risk bounds.

Request a demo See how it works
Built for design partners exploring runtime governance, API abuse monitoring, and explainable enforcement.
event-ledger / risk-decision-chain
Request POST /api/users/login
high sensitivity User and Authentication
Integrity risk1.05
Confidentiality risk1.54
deny

Hazards AUTH_FAILURE_SPIKE and SENSITIVE_ENDPOINT_PROBE crossed configured risk bounds.

Why

Repeated authentication failures on a high-sensitivity route increased integrity and confidentiality risk beyond policy thresholds.

semantic state extracted
hazards activated
risk bounds checked
policy action explained

The gap

Runtime systems make decisions. Security teams need reasons.

Modern observability and security platforms provide rich runtime signals, detections, alerts, incidents, and workflow automation.

RisCoPlane focuses on a complementary layer: making the risk semantics behind runtime decisions explicit. It connects observed behavior to named hazards, multidimensional risk values, policy thresholds, and mitigation decisions in a single traceable decision chain.

RisCoPlane is designed for teams that need runtime decisions to be interpretable, auditable, and tied to explicit operational risk models, especially when deciding whether to observe, alert, throttle, deny, or escalate behavior.

The product

A runtime risk control plane for API services.

RisCoPlane adds a risk-decision layer on top of runtime signals. Configure risk dimensions, hazard definitions, and policies, then connect observed API behavior to traceable decisions about when to observe, alert, throttle, deny, or escalate.

01

Policy-grounded risk modeling

Define hazards, thresholds, and risk dimensions that reflect operational, security, and governance concerns.

02

Traceable decision chains

Connect routes, actors, hazards, and risk dimensions to the policy decision they influenced.

03

Context-aware mitigation

Support observe-only mode, alerting, throttling, denial, or escalation with a recorded rationale.

04

Audit-ready evidence

Export event histories, hazard activations, policy decisions, and risk trajectories for later review.

How it works

From runtime behavior to traceable risk decisions.

1

Observe

Middleware extracts semantic state from API requests, routes, status codes, identities, and other runtime context.

2

Activate hazards

Prefix-based monitors track request history, route sensitivity, behavioral summaries, and conditions that matter to policy decisions.

3

Evaluate risk

Hazards are translated into risk values across configured dimensions such as integrity, availability, misuse, or operational impact.

4

Decide and explain

Policies determine whether to observe, alert, throttle, deny, or escalate, while recording the risk rationale behind the decision.

Product evidence

Every decision leaves an explainable event trail.

RisCoPlane records the route, actor, request, active hazards, risk values, selected action, and explanation behind each policy decision. The ledger shows not only what happened, but why the policy layer continued, throttled, denied, or escalated a request.

Event ledger sample decision rows
Request Route Decision Hazards Risk Why
Request
POST /api/users/login
response 403
Route
/api/users/login
high sensitivity · User and Authentication
Decision deny
Hazards
  • AUTH_FAILURE_SPIKE
  • SENSITIVE_ENDPOINT_PROBE
Risk
  • integrity: 1.05
  • availability: 0.12
  • confidentiality: 1.54
Why Risk bounds crossed on a high-sensitivity authentication route. Detector evidence: 8 authentication-failure observations in 60s exceeded the route-adjusted threshold of 4, and 8 sensitive-endpoint probes exceeded the configured threshold of 6. Route sensitivity increased the loss contribution for authentication and sensitive-endpoint behavior. The resulting risk values were integrity 1.05 / threshold 0.80 and confidentiality 1.54 / threshold 0.66, both crossed. Availability remained within bound at 0.12 / threshold 1.19. Policy action: deny.
Request
GET /api/articles
response 429
Route
/api/articles
medium sensitivity · Articles
Decision mitigate
Hazards
  • ABUSE_RATE
Risk
  • integrity: 0.00
  • availability: 1.20
  • confidentiality: 0.00
Why Availability risk remained above the configured policy threshold. Detector evidence: no new detector crossed its threshold, but the actor remained inside an active cooldown from a previous request-burst decision. The cooldown signal kept ABUSE_RATE active for availability. The resulting risk values were availability 1.20 / threshold 1.19, which crossed, while integrity 0.00 / threshold 0.80 and confidentiality 0.00 / threshold 0.66 remained within bounds. Policy action: throttle, returning response 429 with a shorter public-content cooldown.
Request
GET /api/articles/not-a-real-slug-25
response 404
Route
/api/articles/{slug}
medium sensitivity · Articles
Decision continue
Hazards
  • CLIENT_ERROR_SPIKE
Risk
  • integrity: 0.35
  • availability: 0.66
  • confidentiality: 0.32
Why Hazard active, but all risk dimensions remained within configured policy bounds. Detector evidence: 25 non-auth client errors in 60s met the CLIENT_ERROR_SPIKE threshold of 20. Route-sensitive detector thresholds did not apply. Scenario-adjusted loss produced nonzero risk: integrity 0.35 / threshold 0.80, availability 0.66 / threshold 1.19, and confidentiality 0.32 / threshold 0.66. Since no dimension exceeded its configured bound, the policy allowed the request to continue.

Initial use cases

Start with API risk. Expand toward runtime governance.

API abuse and availability pressure

Translate high-rate behavior, route pressure, and suspicious request patterns into explicit availability and misuse risk decisions.

Sensitive-route risk monitoring

Classify routes by risk sensitivity and explain when behavior crosses configured risk boundaries.

Policy validation and scenario testing

Replay scenarios, tune thresholds, and evaluate whether policy decisions match expected runtime behavior.

Audit and assurance evidence

Produce structured traces of hazards, risk values, policy decisions, and mitigations for review.

Design partners

We are looking for teams with real runtime risk questions.

RisCoPlane is currently in MVP stage. We are looking for platform, AppSec, API security, and governance teams willing to evaluate whether explainable runtime risk monitoring fits their workflows.

Start a conversation

Contact

Request a demo or design-partner conversation.

Tell us what kind of API risk, runtime monitoring, or governance problem you are exploring.

Email: hello@riscoplane.com