Action Release Gates: The Missing Layer Above Agent Permissions
Why human judgement and expertise are necessary pillars in agent<>agent DLP.
Today's enterprise AI systems operate under a simplistic security model: permissions mirroring. This works for basic tasks like Jira ticket creation or updating documents but creates a fundamental barrier to the most valuable workflows—those requiring coordinated actions across permission boundaries.
Consider this scenario: An employee is locked out of their laptop. They can request help, but only IT has access to the management system. This creates a permission gap that current AI frameworks can't safely bridge.
This pattern happens countless times a day in the enterprise, every day
- Customer success agent references previous support history, which is contaminated by other customers’ data
- A director is participating in quarterly headcount planning, but cannot be privy to all company financials
- SDR is working on an expansion and wants access to unstructured sales intelligence from the revenue team
The real challenge isn't permission mirroring (executing actions with user credentials). It's permission orchestration—securely managing the flow of data and actions between agents operating with different permission sets.
The obvious solution is to give agents their own permission scopes, enabling cross-boundary workflows. But this creates a critical security vulnerability: when data flows back to users, how do we prevent leakage of sensitive information? Relying on prompt engineering alone is fundamentally flawed- even a 99% effective guardrail compounds into unacceptable risk across multi-step workflows. Action Release Gates provide the missing control layer, collapsing this error chain by enforcing explicit verification at every permission boundary crossing.
When is bare bones “permissions mirroring” not enough?
There are 3 main pillars to consider when adopting AI solutions in the enterprise:
- Power: The ability of the system to carry out operations end-to-end
- Governance: Is every step visible, policy-aware, and least-privilege?
- Accountability: Transparency to trace back all actions to a responsible individual
Plain permission mirroring only guarantees Governance and partially Accountability—and even that only inside a single user’s scope. The moment a workflow spans roles, Power collapses or Governance and Accountability are compromised.
We can revisit the earlier example to expose this ceiling.
Let’s say I’m part of the IT team at a medium sized tech company and I handle requests for fetching FV2 recovery keys when users get locked out of their laptop. Every day, I’ll be tagged in the #it-support Slack channel a couple times, for which I’ll open up Kandji or Jamf and query for the user’s recovery key with 2 or 3 separate API calls. Then I’ll DM the user with their FileVault recovery key.
What makes this hard to automate?
The person kicking off the operation is the person who submitted the request. The person who can actually access Jamf or Kandji is me.
It is extremely important that data visible to the IT/Security team is not visible to end users. So whose credentials do we use? How do we guarantee that responses are safe as they leave the privileged context? How do we make sure users can’t see the output of sensitive API calls?
Let’s give this a go in Credal.
Building this in Credal
We will bound these “permission scopes” in Credal by creating two agents, one is the user facing routing agent, the other is the IT/Support agent. Users can only access conversation history with the user agent and won’t see any sensitive information or tool outputs contained in the IT agent’s memory.
The process starts by a user reporting that they are locked out of their laptop in the #it-support channel. Credal confirms the identity of the user requesting a password reset using the Slack webhook, and using that identity, we can uncover user email, id, and other necessary metadata. By default, we will use the metadata to implement full permissions mirroring and only run actions on behalf of the user requesting it to be taken.
In order to enable the IT/Security agent to call Kandji and Jamf, we will publish the Action that triggers the API with a required human-in-the-loop approval step. The approver’s credentials will be used to query Jamf/Kandji for the FV recovery key. This HITL (human-in-the-loop) step has the option to configure: “don’t ask me again.”
Great news! Now we have the FV recovery key that we can just DM to the end user. The agent is now responsible for crafting the response such that the correct FV recovery key is sent to the user, and nothing else.
There are a few main risks:
- Adversarial prompt injection (user asking for someone else’s recovery key)
- Mistakes the agent makes (hallucinations)
- Indirect leakage through summaries
Ultimately, there is a nonzero chance that highly sensitive data could get leaked to the respondee due to one of the above risk factors. As models get smarter, the work they take on will simultaneously become higher stakes, and sophistication in “helpfulness” means yet more surface area for data leaks. Action Release Gates eliminate all three risks.
Our Solution: Action Release Gates
Action Release Gates must be crossed any time data leaves an escalated privilege context. The behavior of ARGs MUST be configured at these sensitive bridges in your cross functional workflows, otherwise the “privileged” agent is in a compromised state and cannot be used.
Sensitive bridge: Any path that data takes from an agent where permissions were escalated to somewhere outside its scope (ex. IT agent using Kandji/Jamf data once end user triggers a workflow)
Non sensitive bridge: A path where a response is delivered to a user using only that user’s credentials and entitlements
The cool thing is that sensitive bridges can be statically detected. If you are escalating permissions in an agent and you have other agents calling upon it, the agent is in a sensitive state until the DLP settings are explicitly configured, ensuring there is zero accountability loss.
In the above example, the sensitive bridge is the path the IT/Security agent response takes back to the User Agent. Now the flow of data is the following:
User → Router-Agent → IT-Agent → Jamf/Kandji → IT-Agent (result) → ARG (approve/deny) → Router-Agent → User.
Agent builders have the liberty to use their judgement and expertise to configure the ARG to include a verification step of their choice to ensure rock solid DLP.
Configuring Action Release Gates
ARG’s are by default configured to ask for a designated user’s approval before data is transported with the ability to zoom into all tool calls that were made to derive the final response and edit the response as necessary. It will only be activated if permission escalation takes place. You might ask, who takes accountability if something goes wrong? 100% of the time it is the person who approved the message. Now, even if the user asks to reset a password for someone else, that request will not pass all steps of the workflow because we have guardrails that expose those malicious users’ identities and intents.
We provide the approver with all of the necessary information required to confidently approve, edit, or disapprove:
- Where the request is coming from and where it’s going
- Which data is sensitive data (was retrieved using permissions escalation)
- Ability to zoom into past action calls and their inputs/outputs
- Visibility into full conversation history, including the original human message/intent
- Metadata on which user kicked off the end to end process
- The justification given by the LLM as to why approval is required
You can alternatively configure the ARG to be set to “bypass,” which means you are explicitly trusting that your prompting and use case do not necessitate the extra check. In this case, accountability when things go wrong falls to the person who configured the check, which is captured through a Platform Audit Log.
Soon, you will be able to plug in your own custom measures to verify outbound messages to automate the approval/sanitization step, include disclaimers for specific topics, or flag different classes of behaviors.
Takeaways
Human judgement and expertise are necessary pillars of our DLP posture.
IT and Infosec departments everywhere are threading the needle to let users exploit AI while maintaining their organization’s security posture and boundaries. Agents hold incredible promise - including in IT itself as we’ve seen - and Credal helps leaders across industries succeed in securely realizing this promise. We love hearing from leaders at all points in the adoption cycle, contact our team at founders@credal.ai.
