Do you need approval workflows for LLM calls that are authenticated with Okta?
Most teams let a developer’s Okta token travel straight to an MCP server. The token proves identity, the server trusts it, and the request executes immediately. In that model the request bypasses any gate that could verify whether the operation aligns with policy, and there is no record of who asked the model to generate a particular response. Sensitive prompts, customer data, proprietary code, or security‑related queries, can leave the organization without any audit trail.
Because the request reaches the MCP endpoint directly, the only control is the static permission granted to the Okta client. That permission is often broad: any user in a group can invoke the model, and the model can return raw output without any human check. The setup therefore fixes authentication (who is calling) but leaves the critical enforcement gap open. No approval step, no command‑level audit, and no way to block a risky prompt before it is processed.
Why approval workflows matter for LLM gateways
LLM gateways expose powerful generation capabilities. An unvetted prompt can cause data exfiltration, policy violations, or generate disallowed content. An approval workflow inserts a decision point where a designated reviewer can examine the prompt, confirm its legitimacy, and explicitly allow it to proceed. The workflow also creates a record that links the request to the approving individual, satisfying internal governance and external audit requirements.
Implementing such a workflow requires three distinct pieces:
- Setup: an Okta‑issued token that identifies the caller and conveys group membership.
- Data path: a proxy that can intercept the request, enforce policy, and trigger the approval step.
- Enforcement outcomes: the actual pause, reviewer interaction, and audit log that only exist when the proxy is present.
Placing the proxy in the data path
When the proxy sits between the Okta identity and the MCP server, it becomes the single place where every request can be examined. The proxy reads the token, validates the caller, and then checks the request against a policy that requires approval. If approval is needed, the proxy holds the request, not the MCP server, and forwards it only after a reviewer approves it. Because the proxy controls the traffic, it can also record the full session for replay, mask any sensitive fields in the response, and enforce a deny‑list of disallowed commands.
In this architecture, the proxy is the only component that can guarantee that an approval workflow is enforced. Removing the proxy would instantly eliminate the pause, the audit entry, and any masking, returning the system to the original uncontrolled state.