A framework that names the gap precisely
There is now an analyst category — ARISE, Agentic Runtime Identity Security Enforcement — for the class of problem that enterprise security teams have been circling since AI agents went into production. The category was identified by SACR and validated by Gartner’s 2026 Hype Cycle for Digital Identity, which placed both AI Agent Identity and Intent-Based Access Control at the Innovation Trigger stage with a High benefit rating. Those two capabilities are the foundation of what ARISE describes.
The reason a new category needs to exist is that the existing alphabet of security frameworks — IAM, NHI, CSPM, SIEM — was built for a different threat model. Traditional access control assumes deterministic systems: a service account that does the same thing every run, a human identity that maps cleanly to a role, a request that either conforms to its application’s intended behavior or has clearly been tampered with. AI agents break all of those assumptions. They are non-deterministic. The same agent, given the same task, may take different paths to complete it. The scope of what they need is contextual and changes with the conversation. And when multiple agents delegate to each other, accountability can evaporate entirely across the chain.
ARISE defines six capabilities a complete governance platform has to provide. They are worth naming precisely, because understanding where each sits in the architecture tells you which ones are solved problems and which ones remain infrastructure gaps.
The six capabilities and where they live
Discovery without prior knowledge — finding every agent operating in the environment, including shadow agents that were never formally registered. This is primarily an inventory and observability problem, solved at the network and endpoint layers through traffic analysis and integration with existing security tooling.
AI agent identity — establishing a verified identity, a documented human owner, and a structured organizational intent baseline for every discovered agent. This is the IAM and NHI layer: assigning non-human identities, scoping credentials, and maintaining the registry. The Gartner category referenced is the correct category for this work.
Organizational intent capture — defining what each agent was built to do in a structured, role-based form that becomes the authorization baseline. This is where the framework stops being abstract and most implementations stop entirely. “This agent handles customer support enquiries” is not an organizational intent baseline. A structured declaration of which HTTP methods may be called, against which paths, with which parameter constraints, under which conditions — that is.
Runtime behavioral governance — continuously evaluating agent behavior against the organizational intent baseline at the point of execution, not after the fact. This is the enforcement problem. It requires a deterministic control point sitting on the request path that evaluates every outbound call in real time. Logging and alerting after the fact is not governance; it is forensics.
Intent drift detection — identifying when an agent’s behavior progressively diverges from its intent baseline at the session level and the trend level, and responding with graduated controls.
Cross-chain authorization integrity — maintaining accountability across multi-agent chains and ensuring that authorization scope can only decrease, never expand, across delegation hops.
The first two capabilities live at the identity and network layers. The last four all require something operating at the point where agent behavior becomes HTTP calls. That is where most enterprise stacks have nothing.
The problem with governance that lives above the wire
The ARISE framework is precise about why runtime behavioral governance must operate “at the point of execution, not after the fact.” The reason is not just latency — it is that the agent’s behavior is the execution. If the check happens after the call completes, the damage is already done: the data has been returned, the record has been written, the payment has been initiated. Post-hoc evaluation produces an audit trail, not a control.
This gap is not a failure of the identity layer. Identity tools are doing exactly what they were built to do. An AI agent that authenticates as a registered, well-governed non-human identity and then issues a call it was never authorized to make has a correct identity. The identity layer has no information about whether that specific call — this method, this path, this parameter, this moment — should be permitted. That question only has an answer at the wire.
The same gap explains why governance documentation, system prompt instructions, and application-layer guards do not satisfy ARISE’s runtime behavioral governance requirement. A prompt instruction lives in the same context window as every other instruction competing for the model’s attention. Application-layer guards are procedural code: invisible to security review, untestable in isolation, and specific to the agent framework they were written inside. Neither produces a deterministic outcome. ARISE’s framing — “behavioral governance that operates at machine speed” — requires determinism, not probability.
How intent capture becomes enforcement
The most important shift ARISE introduces is the idea that organizational intent is not a narrative description of an agent’s purpose. It is a structured, evaluable artifact — the thing that a runtime governance system actually checks calls against.
In RequestRocket, that artifact is the rule set on a proxy. A proxy configured with proxyDefaultRuleEffect: "deny" starts in the correct ARISE posture: nothing is permitted until organizational intent explicitly authorizes it. The rules attached to the proxy are the operationalized expression of what this agent was built to do:
{
"effect": "allow",
"ruleActive": true,
"methods": ["GET"],
"path": {
"path": { "pattern": "^/v1/accounts/[^/]+$" },
"presence": "must_exist"
},
"notes": "Agent may read a single customer account by ID"
}This is not pseudocode. These are the exact fields you POST to /clients/{clientId}/proxies/{proxyId}/rules. The second rule does not just permit the /v1/refunds endpoint — it encodes a constraint: the amount field must match the pattern for integers between 1 and 100. If the model generates a request for a $50,000 refund — through a reasoning error, a prompt injection, or a legitimate but wrong inference — the proxy refuses the call before it reaches the upstream payments API. The agent receives a denial; the upstream system never sees the attempt.
This is what organizational intent capture as an authorization baseline means in practice. Not a sentence describing the agent’s role, but a machine-evaluable description of what calls are permitted. The fact that it is also a JSON object stored in version control, reviewable in a pull request, and diffable between environments is not incidental — it is how ARISE’s audit requirement is met. The Git history of the rule set is the record of what the organizational intent baseline was at any point in time.
The data minimization half of runtime governance
ARISE’s runtime behavioral governance requirement covers both directions of the call. An agent that is allowed to read a customer record and receives a response containing that customer’s payment method, stored credentials, and internal notes has been given more than its organizational intent authorizes — regardless of whether the call itself was permitted.
This is the piece most access control implementations skip entirely, and it is the piece that matters most for AI agents. Anything that lands in the model’s context window can be extracted by a subsequent instruction, surfaced in a log, or used as a vector for indirect prompt injection. The organizational intent for a customer support agent does not include access to stored payment credentials, and the fact that the API returns them in the same JSON object as the account status is irrelevant — the governance layer should have stripped them before the agent ever received the response.
RequestRocket’s response filters enforce this at the wire level. A filter defines which fields to retain (keeping only what matches, destroying everything else) or destroy (removing specific fields and keeping everything else) from the upstream API’s response before it reaches the agent:
{
"filterActive": true,
"methods": ["GET"],
"requestPath": {
"path": { "pattern": "^/v1/accounts/" },
"presence": "must_exist"
},
"operations": [
{
"effect": "retain",
"jsonPath": { "pattern": "^(accountId|name|status|openTickets)$" },
"notes": "Pass through only fields the support workflow requires"
}
],
"notes": "Strip PII, payment data, and internal notes from account responses"
}After this filter runs, the account record the agent receives contains four fields. The payment method is not present. The internal notes are not present. The phone number and email address are not present. There is nothing to exfiltrate, because there is nothing there to find. The model’s context window contains exactly the minimum the task requires.
Cross-chain integrity: scope can only decrease
ARISE’s cross-chain authorization integrity requirement states that authorization context must travel with a multi-agent chain and that scope can only decrease, never expand, across delegation hops. This is the correct constraint, and it has a direct structural implementation.
In a multi-agent architecture where an orchestrator dispatches tasks to sub-agents, each agent in the chain should have its own proxy with its own rule set, and those rule sets should form a strictly decreasing permission hierarchy. The orchestrator may have broad scope — it may be permitted to read accounts, query order history, check inventory, and create support tickets. The sub-agent it dispatches to handle a specific refund decision should have a rule set that is a strict subset: read a single account by ID, issue one refund. That is all.
The constraint is not negotiated at runtime by the agents themselves — it is enforced by the proxy each agent calls through. An orchestrator cannot grant a sub-agent permissions the sub-agent’s proxy doesn’t hold. The agent-level credential authenticates the caller to a specific proxy, and that proxy’s rules define the ceiling. Scope can only decrease because each proxy is an independent control point, not because any agent in the chain is trusted to respect a policy document.
This is what “authorization context travels with the chain” means in a deterministic implementation: not metadata attached to inter-agent messages, but a separate enforcement point on every outbound call from every agent in the chain, each with a rule set that encodes that agent’s organizational intent baseline.
Intent drift detection: volume as a behavioral signal
Intent drift — the progressive divergence of an agent’s behavior from its organizational intent — manifests in two ways. Semantic drift is when the calls the agent makes shift in character: it starts calling endpoints its intent baseline did not authorize, it begins testing path patterns it was not given, it queries for data it has no organizational reason to need. The rule set catches this immediately — an unauthorized call is denied on the first attempt, not after a pattern of drift accumulates.
Volume drift is subtler. A sequence of calls that individually comply with the rule set can collectively describe behavior the organizational intent never contemplated. A support agent that reads one customer account per interaction is compliant; the same agent reading forty thousand account records over a weekend is something else. Each individual call is permitted; the aggregate is the anomaly.
This is where metering operates as a behavioral governance control. A rate limit is not just a cost control — it is an expression of the expected behavioral envelope:
{
"meterType": "request_count",
"meterActive": true,
"limits": {
"minute": 10,
"hour": 200,
"day": 2000
},
"notes": "Customer support agent: expected interaction volume"
}An agent interacting with customers through normal workflows will stay within these thresholds comfortably. An agent that has been redirected — through prompt injection, a runaway loop, or a slow-extraction attack — will hit the ceiling. The ceiling is not punitive; it is the quantified expression of what the organizational intent implies about volume. When the meter trips, the proxy stops forwarding calls. The exfiltration attempt hits a wall.
Where RequestRocket sits within the ARISE stack
Honest accounting: RequestRocket is not a complete ARISE platform. It does not discover shadow agents that have never been formally registered. It does not establish AI agent identities or maintain the registry of human owners. Those are identity and network layer problems that the NHI and agent identity tooling categories are built to solve.
What RequestRocket provides is the enforcement layer that the rest of the ARISE stack depends on. The other five capabilities can be implemented without a runtime enforcement point, but they will remain governance documentation rather than governance infrastructure. The organizational intent baseline that ARISE requires you to capture is only meaningful if it is evaluated against every call the agent makes. The cross-chain authorization integrity that ARISE requires you to maintain is only achievable if there is a control point on each hop that cannot be bypassed by the agent. The intent drift detection that ARISE requires you to perform is only possible if a behavioral baseline is being enforced in real time, not reconstructed from logs after the fact.
This is the seam the AI agent access control landscape maps as the unsolved egress layer: the point between your agents and the APIs they call where every outbound request and every inbound response is evaluated against a deterministic policy. The identity layer tells you who the agent is. The ARISE intent capture layer tells you what it should do. The egress enforcement layer is the thing that makes “should” mean anything.
Next steps
The practical starting point for ARISE-aligned governance is a single agent. Write the shortest complete list of API operations that agent actually requires — every permitted method, path, and parameter constraint — and express each one as a rule on a deny-by-default proxy. Add a filter for each response type that strips the fields the agent’s workflow never needed. That rule set is your organizational intent baseline, enforced on every call, auditable from the first request.
RequestRocket is built for exactly this: runtime access control over the APIs your agents call — every call gets a least-privilege credential, a policy check, payload filtering, and an audit record, with no changes to your agent code or the upstream system. Read the documentation for the full proxy, credential, rule, and filter reference, or start for free.