The problem :

• Moving AI agents from single-user desktop demos to enterprise production means solving a brutal engineering problem: multi-user, multi-system delegated authorization.

core design principle (non-negotiable) : treat every agent action as delegated user access, never as the agent's own blanket access

• TODO :

Defining the Threat Model :

• Issue is that if you give agent its own identity, then a person with less access can have higher access using the agent
• Give the agent access equivalent to a user and prompt injection can compromise the system.

Solving the Threat Model :

Tackling the confused deputy attacks

• If user A has given escalated permissions to user B, then it is the responsibility of user A if user B triggers something malicious.
• Human in the loop (human-ai interpretability)
  • Any request flagged by us, even if it’s safe and allowed by you ends up asking for permissions. Why ? If the system of A is compromised and it has given permissions to system A, it could be disastrous. Our checker system monitors all requests and flags with a UI warning with human in the loop to verify and run it.
  • This is done by the UI layer triggering a prompt to the user asking for approval to carry out that action, along with severity and warnings.
  • Issues here ? : dialogue fatigue
  • Research goals : How to make human interaction minimal but also validated
    • Run some requests in sandboxed mode and verify the trace of system access in an deterministic way ? think zk/verificable/provable something. Requires spinning up the system.
• Also we’re betting on someone to find a better solution to the prompt injection problem. This is a work in itself.

Targeting the authorization flow

• What if an attacker intercepts request, modifies it and sends it himself ?
  • Not possible - why ?

The 2 identity model

• In general, the solution to the 2 identity problem defined in the threat model is evaluating BOTH what agent is allowed to do and user is allowed to do at runtime.
  • With respect to hop is, the agent what allowed to do is the client side infra which we are betting on will improve individually as well.
  • Hop’s v4 has a policy engine as a feature where you could also define what agent is allowed to do and the request before even hitting the agent gets verified against it. The client also has the same policies which could be applied and catered to client side, hence making the control granular refined on client side as well.
  • The user what being allowed to do is the trust layer hop manages. Hop’s deterministic + non deterministic policy engine layer which clearly takes in prompts and decides if the (resource, action) is allowed for this user or not.
  • <INSERT DIAGRAM>

The difference from enterprise is that trust layer in enterprise needs to be a