Blog

ARISE Implementation: Three Steps to Runtime Control

·5 min read

You do not have to buy the whole sky

The ARISE Playbook’s implementation chapter is more useful than most category launches. Building full ARISE takes budget, a vendor decision, and a quarter of someone’s time. You still start this week with tools you own – we listed them in shadow agents. When you are ready to build, the Playbook is three steps: see everything, establish agent identity and organisational intent, add runtime enforcement.

SACR’s CISO recommendations rhyme: start with deterministic governance but do not stop there; invest in observability before fancy dynamic policy; make an explicit choice about non-deterministic governance (false positives are real); map your agent archetypes before you pick a vendor; treat MCP as its own requirement.

This post in our ARISE series is the assembly guide. RequestRocket is not the entire stack. It is the outbound enforcement and per-call record that Steps 2 and 3 need once Step 1 has produced names.

Step 1 – See everything

Deploy discovery that does not depend on self-registration. In every environment the Playbook authors have assessed, the actual number is higher than the approved number, and the access is broader than anyone authorised. Continuous, not a scan you frame.

Owners of this step: EDR, MDM, IdP (OAuth grants), SaaS admin centres, NHI/agent-discovery vendors (Astrix, Entro, Token, Cyata, Microsoft Agent 365, Runlayer Watch – pick from SACR’s map, not from a tweet). RequestRocket does not discover Claude on a laptop. If you skip this step and only put a proxy in front of the one agent engineering admitted to, you have governed the well-behaved intern.

Output you should demand: a list of agents and AI clients, a human owner or an explicit “orphaned,” the credentials they use, the systems they can reach. The Playbook’s diagnostic three – can you answer blast radius and this-week-versus-last-week in real time – is the quality bar, not a logo on a slide.

Step 2 – Identity and intent, not a wiki page

For each discovered agent that touches a core process:

Verified identity of its own. Not the Finance user’s OAuth token. A persistent caller credential, or a JWT from the IdP you already run, unique to that agent. Failure mode one is what you are closing. Microsoft’s sponsorship model and Okta’s certification campaigns are the IAM-shaped version of owner and review. Use them. Then make sure the wire identity matches the directory object.

Documented human owner. Lifecycle: handoff, fork, retire. Same discipline as offboarding a person, at agent pace.

Structured organisational intent. Role, systems, data, actions. Not a paragraph. The Playbook’s Principle of Least Agency: confirm the autonomy is necessary. Failure mode two is what you are closing. In RequestRocket that artefact is deny-by-default plus rules (and filters, and meters). In your IdP it might be a group that may invoke the agent at all. Both layers. Neither layer alone.

Least agency on the credential path. Vault the vendor key. The agent never holds the Stripe secret. Rotation and revoke become operator actions, not archaeology.

Do this for the highest-blast-radius agents first – Finance, identity stores, production change – not for the summariser.

Step 3 – Runtime enforcement, observation first

The Playbook: deploy the layer that evaluates behaviour against intent at the point of operation. Start with observation before aggressive intervention. Build baselines from real behaviour before you tune response policies. For multi-agent work, add cross-chain integrity: map the chains, track authorisation context on the highest-risk ones, expand.

SACR’s three layers, translated:

LayerWhat you implement firstWhat you add when you trust the data
Deterministic governanceAllow/deny on method and path; vaulted secrets; deny-by-defaultFiner body constraints; per-tool MCP scope
ObservabilityPer-call identity, decision, upstream, timing into SIEMReasoning traces from the runtime; DSPM labels on payloads
Dynamic governanceMeters as ceilings; credential revoke as kill switchHITL on high-risk privileges; guardian intent checks; risk scores

RequestRocket is built for the first column and the left half of the second: the call either proceeds or it does not, and you have a record either way. Prompts are not this layer. Anomaly models on service-account baselines are not this layer. Meters are the first dynamic control that does not require a second AI to police the first.

Cross-chain: separate caller identities per hop, shrinking allow-lists, telemetry that still names the human sponsor. You will not get cryptographic “intent tokens” across every vendor this year. You can get “scope never increased because the sub-agent’s proxy would not allow it.”

A reference path that does not rip out Okta

A realistic production path:

  1. Human signs into the agent client with Entra or Okta.
  2. The agent presents a JWT or a per-agent API key to RequestRocket. Conditional access and MFA stay on the IdP. You are not running a shadow SSO.
  3. RequestRocket checks rules, meters, filters, injects the vaulted vendor credential, forwards to Salesforce / the MCP server / the payments API.
  4. Telemetry streams to Splunk or Datadog next to Okta System Log. Incident question: who, which agent, which decision, which upstream – without waiting on the vendor.
  5. Optional: a guardian / NHI / MCP-runtime product consumes the same intent document and the session transcript. Optional: LLM gateway for model spend. Optional: EDR enforce for unapproved local servers.

That is architectural layering, which SACR says you should expect. The combination that fails audits is the common one: identity plus integrations plus nothing on the outbound call.

Self-hosted data plane is an enterprise conversation if residency requires it. It does not change the three steps.

What to tell the CISO who wants to wait

Pingree’s Formula One CISO, waiting for the last lap: the market is not allowing that pace. The Playbook’s close: the window is open because the category is new and most enterprises have not built it; the ones that do will put agents in core workflows while competitors keep AI at the edges.

You can still sequence. You cannot sequence forever on Step 0. Run discovery this week. Put one core-process agent on a proxy this month. Take the scorecard to the steering group so “we are doing ARISE” has seven boxes, not a vendor logo.

Next steps

If Step 1 is a blank page, start with shadow agents. If you already have a list, issue caller credentials and a deny-by-default intent list for the noisiest Finance or CRM agent. Documentation covers the objects; signup is the first proxy.

Enhance ISO 27001
Enhance SOC 2
Enhance GDPR
Enhance HIPAA

Add outbound API security
without changing code

Start on your own or talk to our team about improving the security of every API call you make.