Blog

ARISE Requirements: A Scorecard for Agent Governance

·5 min read

Seven boxes, not a category tattoo

The ARISE Playbook ends with a window: the category is named, the architecture is converging, and most enterprises have not built the infrastructure it describes. The way to use that without a bake-off is a scorecard. Seven requirements. For each, what “none / partial / enough to defend” looks like, and which system actually owns the work.

This is the last post in our ARISE series. It assumes you have met the failure modes – borrowed identity, scope collapse, broken anomaly detection, cost as drift, MCP and protocol gaps – and the design rules: infrastructure not prompts, data least privilege, democratisation as the trigger, three implementation steps.

Score yourself in a room that includes IAM, the SOC, platform engineering, and whoever owns the first Finance agent. If only security is present, you will over-score discovery tools and under-score intent.

Three questions before the seven

The Playbook’s Section 04 is the entrance exam:

  1. Where is AI already touching core processes? Edge summarisation is not the issue. Ledger, CRM, HR, production change are.
  2. How many agents are actually running – not how many you approved? If the answer is “we think we know,” stop and do discovery. Gravitee’s 14.4% full-approval figure is the base rate, not a scandal about other companies.
  3. Can you see risk and blast radius continuously? Current risk, systems in reach, consistency with last week, how invocation is changing. After-the-fact log review is not a yes.

If you fail these, the seven requirements are theatre.

The scorecard

1. Discovery without prior knowledge

  • None: register-if-you-feel-like-it; SaaS AI features unknown.
  • Partial: one EDR query, a spreadsheet, already stale.
  • Defendable: continuous endpoint + MDM + IdP grant review + SaaS admin, orphaned agents flagged. Owner: security operations and IAM, with an NHI/agent-discovery product if the estate is large.
  • RequestRocket: does not discover. Consume the list.

2. Identity lifecycle management

  • None: shared keys, departed employees’ OAuth grants still live.
  • Partial: directory objects for some agents (Entra Agent ID, Okta), no join to the credential on the wire.
  • Defendable: every core-process agent has a unique caller identity, a human sponsor, provision/handoff/retire tracked, vendor secrets vaulted and rotatable. Owner: IAM + platform. IdP for the principal; outbound proxy so the vendor API is not the identity.
  • RequestRocket: per-agent caller credentials, JWT verify against your IdP, vaulted target credentials. Not the HR-style workflow UI – pair with the IdP you have.

3. Organisational intent capture

  • None: a Confluence paragraph, or the system prompt.
  • Partial: coarse IdP scopes (“Salesforce connected app”).
  • Defendable: role-based, machine-evaluable baseline – systems, actions, data – reviewed like a role. Least agency checked. Owner: business owner + security, stored where change control exists.
  • RequestRocket: deny-by-default, rules on method/path (and tighter constraints when you need them). This is the artefact we mean by intent on APIs you do not own. Longer form.

4. Runtime intent observation

  • None: vendor dashboards and laptop console logs.
  • Partial: SIEM has some agent traffic, no standard schema, no allow/deny on the hop.
  • Defendable: every outbound call attributed to agent + human + decision; tool sequence and data pattern available; can pause or refuse the next call. Owner: platform on the wire, SOC on the stream. Runtime vendors for reasoning traces.
  • RequestRocket: the hop and the record. Not chain-of-thought. Why UEBA is the wrong centre.

5. Intent drift detection

  • None: quarterly access recertification only.
  • Partial: alerts on 5xx or spend, no envelope.
  • Defendable: session, trend, and (for multi-agent) chain views; graduated response – recommend, restrict, stop. Cost envelopes included, because optimisation shows up as volume.
  • RequestRocket: meters as live ceilings; denials as semantic drift; telemetry for trend. Guardian/NHI products for slower semantic drift inside the allow-list. You want both.

6. Cross-chain authorisation integrity

  • None: orchestrator and workers share one key.
  • Partial: separate identities, same allow-list.
  • Defendable: scope only decreases; each hop verifiable to the originating authorisation without folklore. Owner: architecture. Hard in 2026 across vendors. Do the high-risk chains first.
  • RequestRocket: separate proxies and credentials per hop, shrinking rules, one audit stream. Not a cryptographic intent token standard. Honest gap for the industry, not only for us.

7. Incident-ready accountability

  • None: reconstruct from the victim’s blog post. (If that sentence stings, read audit logs.)
  • Partial: logs of what happened, not whether it was authorised against the baseline at that time.
  • Defendable: Playbook’s bar – baseline, believed authorisation, consistency, delegation hops, scope reductions. Tamper-evident enough for audit, streamed to SIEM, retained to policy.
  • RequestRocket: per-call decision records you can export. Pair with IdP events and, where required, immutable archive (S3 and peers). Logs without the intent baseline attached are still just logs – keep the rule history under change control.

How to talk about vendors without lying

SACR’s conclusion: no single vendor fully owns deterministic governance, behavioural analysis, and dynamic intent equally. aizome will tell you they are a founding ARISE platform. Identity vendors will tell you Agent ID is ARISE. MCP gateway vendors will tell you the protocol choke point is ARISE. We will tell you the outbound call is the enforcement ARISE is hollow without.

All of those can be true in a stack. None of them is true as a monopoly. The Playbook’s aizome close is their product. Your scorecard should survive a world in which you keep Okta, add discovery, and put RequestRocket in front of the APIs you do not own. That composition is the point of the landscape.

The window

Enterprises that can put agents into core processes with a defendable story will do it. The rest will keep AI at the edges and still accumulate BYOA in Finance, because democratisation does not wait on a RFP.

Pick the requirement you scored “none.” If it is 1, run the Playbook queries. If it is 3–5 or 7, you are in the outbound seam: identity you can name, intent you can evaluate, a record you can show. That is runtime access control for AI agents and apps calling APIs you don’t own – every call a least-privilege credential, a policy check, and an audit record, with no code changes.

Start for free. Series index: ARISE is here. Your API gateway isn’t ready.

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.