4 ms·

Nice project! Quick question: how do you handle LLM access control in practice? For example, can different steps in a workflow run under different credentials o

Nice project! Quick question: how do you handle LLM access control in practice? For example, can different steps in a workflow run under different credentials or provider accounts, and is that enforced centrally by AxonFlow or delegated to the underlying orchestrator? Thanks!

saurabhjain1592 9mo ago
Thanks. In practice, access control is enforced centrally by AxonFlow, not delegated to the orchestrator. Each LLM or tool call is evaluated at execution time against the active policy context, which includes the user, workflow, step, and tenant. That allows different steps in the same workflow to run under different credentials, providers, or cost and permission constraints if needed. In gateway mode, the orchestrator still issues the call, but AxonFlow pre-authorizes it and records the decision so the policy is enforced consistently. In proxy mode, AxonFlow holds and applies the credentials itself and routes the call to the appropriate provider. The key point is that credentials and access rules are defined once and enforced centrally, while orchestration logic remains separate.
- fpierfed 9mo ago
  What kind of latency does this generate? I guess for LLM operations the extra latency might not bet that important. Is that correct?
  - saurabhjain1592 9mo ago
    Good question. The overhead is designed to be low enough for inline enforcement. For the fast, rule based checks we typically see single digit millisecond evaluation time, and in gateway mode the end to end pre check usually adds around 10 to 15 ms. You’re right that relative to an LLM call this is usually negligible, but we still treat it seriously because policy checks also sit in front of tool calls and other non LLM operations where latency matters more. That’s why the static checks are compiled and cached and the gateway path is kept tight. If you want more detail, I have a longer architecture walkthrough that goes into the execution path and performance model: https://youtu.be/hvJMs3oJOEc https://youtu.be/hvJMs3oJOEc
    - fpierfed 9mo ago
      Understood. Pretty cool, good luck with the project!

saurabhjain1592 9mo ago

Thanks. In practice, access control is enforced centrally by AxonFlow, not delegated to the orchestrator. Each LLM or tool call is evaluated at execution time against the active policy context, which includes the user, workflow, step, and tenant. That allows different steps in the same workflow to run under different credentials, providers, or cost and permission constraints if needed. In gateway mode, the orchestrator still issues the call, but AxonFlow pre-authorizes it and records the decision so the policy is enforced consistently. In proxy mode, AxonFlow holds and applies the credentials itself and routes the call to the appropriate provider. The key point is that credentials and access rules are defined once and enforced centrally, while orchestration logic remains separate.

fpierfed 9mo ago
What kind of latency does this generate? I guess for LLM operations the extra latency might not bet that important. Is that correct?
- saurabhjain1592 9mo ago
  Good question. The overhead is designed to be low enough for inline enforcement. For the fast, rule based checks we typically see single digit millisecond evaluation time, and in gateway mode the end to end pre check usually adds around 10 to 15 ms. You’re right that relative to an LLM call this is usually negligible, but we still treat it seriously because policy checks also sit in front of tool calls and other non LLM operations where latency matters more. That’s why the static checks are compiled and cached and the gateway path is kept tight. If you want more detail, I have a longer architecture walkthrough that goes into the execution path and performance model: https://youtu.be/hvJMs3oJOEc https://youtu.be/hvJMs3oJOEc
  - fpierfed 9mo ago
    Understood. Pretty cool, good luck with the project!