3LS Platform / AI Gateway
Classify selected prompt text, select among approved models, track usage and apply cost controls on traffic passing through the 3LS gateway. On configured protected response paths, inspect model-generated tool calls before they reach the agent harness.
The harness is the client runtime that receives model responses and dispatches tools. The gateway sits on the supported provider route; its protected response gate acts before a tool proposal is delivered to that runtime.
3LS Gateway
Classification · policy · eligible model selection · usage controls
Gateway response / tool gate
Inspect selected fields · release or withhold response
Response inspection applies to configured protected response paths and selected tool/argument fields. Release and withholding require enforcing policy on that path. Withheld proposals are not delivered for dispatch; a release does not authorise backend execution. Direct provider and backend access requires separate controls.
Tool security before the harness
Review model-proposed tool calls and selected arguments before release on configured protected gateway paths. Keep a rejected proposal from becoming a tool instruction delivered to the client runtime.
For example, a model proposes a tool call whose selected argument fails the configured rule. The gateway withholds the protected response before harness delivery and records the decision. Confirm the provider endpoint, response format, streaming path, tool definition and inspected fields for your workflow.
Prompt classification
Classify selected prompt text using configured stages. Keep topic/activity labels and risk signals separate from each other and from action permissions, so a useful task label does not become an execution grant.
For example, a topic stage identifies drafting while a separate risk stage reports NoSignal. Enforcing stages apply their configured denial rules and requirements; observational stages cannot grant or deny. Optional-stage gaps remain evidence and cannot grant access.
Explore activity classification →Model routing
Use policy, configured classification outcomes and permitted user or session choices to select an eligible model. Routing chooses which candidate handles a request, rather than only listing models that are allowed.
For example, a configured activity preference selects the economical role from two eligible candidates. A permitted session choice may retain or promote a model within the configured rules. Current eligibility, endpoint compatibility and signed bindings remain part of the selection boundary.
Review the available candidate set, selected model and recorded selection reason where available. Agree supported providers, model identifiers, compatibility and permitted choices for your deployment.
Cost control
Attribute usage and cost, apply request-rate controls and configured monthly thresholds, and use permitted model choices in routing. Review reported, estimated and unknown usage or cost alongside reporting freshness.
For example, a provider attempt has known token usage but an estimated cost based on configured prices. Unknown usage remains unknown rather than becoming zero. Separate classifier usage and cost from the parent model call where the available record provides that attribution.
Monthly threshold action is delayed and can overshoot while reports and signed controls are applied. Request-rate controls govern admission; they are not an instantaneous invoice cap. Review current applied controls, freshness and pending reporting with the usage totals.
Agree provider accounts, approved models/routes, tool groups, selected inspection fields, classification stages, routing rules, permitted choices and usage controls. Confirm client compatibility, identity, policy application, hosting and the evidence handoff for your environment.
The four records above are independent illustrative examples of configured workflows. They do not depict one automatically joined request, tool execution and case history. Central evidence uses bounded fields rather than the raw submitted prompt or tool argument.
Read Technical Docs →The gateway checks a provider-proposed tool call before protected response delivery. Withholding a proposal does not authorise backend execution or contain an independently executed action.
On supported managed MCP paths, original argument checks and configured approvals can precede backend dispatch.
Managed MCP result inspection occurs before returned-result delivery. A result denial cannot undo an effect already executed.
Map the request, model selection, tool-proposal check and usage controls with your team.
From the blog
Research on tool authority, provider routes and the control boundaries that surround agent workflows.
A user asked to move up a gym waitlist. His assistant reportedly cancelled someone else's reservation and could not restore it. The failure sat between a legitimate goal and an unauthorised method.
OpenAI rebuilt the service, but the agents recreated their shared channel. The incident shows why enterprises must control persistent state, credentials, communication paths, and delegated authority themselves.
Prompt warnings and approval clicks do not contain a tool-enabled agent. Hard execution policy does.