Skip to main content
Once you have defined your rules, rulesets, and stages, you are ready to invoke runtime protection in your application.

Invoke runtime protection

Runtime protection is invoked by calling the SDK, passing a payload and the stage. The Payload has an input and output as required, depending on the metric (see the metrics in the rules for more information on what metrics need input, output, or both). You can set the stage either by name or Id, and optionally provide a version. If you don’t provide a version, the latest version of the stage is used.

Invoke runtime protection with a central stage

When using a central stage, the stage needs to be created with rulesets. This can be created at any time, but is best practice to control these via scripts managed by central IT, AI governance, or operations teams who can control stages at an organizational or team level. These teams can then manage the stages independently of the application development teams.
Then once the stage is created, it can be used in runtime protection.
To run runtime protection synchronously, use the invoke_protect method:

Invoke runtime protection with a local stage

When using local stages, the stage needs to be created without any rulesets. This can be created at any time, including in your application (after checking to see if it already exists), or as part of your deployment.
Then once the stage is created, it can be used in runtime protection.
To run a local stage synchronously, use the invoke_protect method:

Set a timeout

Sometimes responsiveness is more important than enforcing runtime protection. When you invoke runtime protection, you can set a timeout in seconds. If this timeout is hit, the call returns a response status of timeout. The default value if this is not set is 300 seconds (5 minutes).

Runtime protection responses

When you invoke runtime protection, it will return a Response object. This has two properties of interest, status and action_result. The typical flow is:
  • If invoking runtime protection returns triggered, then check the action result to see what to return.
    • If the action result is passthrough, return to the user a response that is handled in your application logic, and stop the current workflow.
    • If the action result is override, return the provided choice to the user, and stop the current workflow.
  • If runtime protection returns not triggered, or paused, continue with your application workflow as normal

Response status

The response status can be one of a range of ExecutionStatus values.

Action result

If the status of the stage is triggered, then the action result returns the result based on the action set on the highest priority ruleset that was triggered. If this is a passthrough action, then the action result is passthrough, if this is an override action, then the result is a randomly chosen value from choices set on the action.
This code will trigger the rule, returning a random choice from the override action choices.

Runtime protection basics

Learn the basics of running runtime protection.

Rules

Learn about defining rules for runtime protection.

Rulesets

Learn about defining rulesets for runtime protection.

Stages

Learn about defining stages for runtime protection to be used during different stages in your application workflow.