Authorize model access
Give the workload a Cortega identity and approved models, instead of distributing unrestricted provider keys.
Resources / How-to guide
How to connect OpenShell agents to Cortega.
Run the agent inside OpenShell and send its model requests through Cortega. Keep sandbox restrictions alongside approved model access, security guardrails and budgets.
Apply security and spend policy
Use configured guardrails and budgets on requests routed through Cortega.
Retain execution restrictions
Keep OpenShell’s filesystem, process and network policies around the agent.
How it connects
Route model and tool requests through Cortega.
Employee or serviceTask and authenticated identity
External contentMessages, pages and tool results
Potential attacker instructions
Potential attacker instructions
↓ Task and context
OpenShell agentSandboxed files, processes and network access
→CortegaModel access · guardrails
Budgets · request records
→Budgets · request records
Approved modelsHosted providers or
private inference
private inference
Tool pathOpenShell agent → Cortega MCP gateway → authorized tools
Connect supported MCP tools separately. Keep record permissions at the destination.
Setup
Configure the connection.
01
Prepare the Cortega identity and policy.
Register the models the agent may use. Assign its identity to a team with the required model authorization, guardrails and budget. Keep upstream provider credentials in Cortega. Use a separate workload identity when you need to revoke this agent’s access independently.
02
Create an OpenShell provider profile.
Define a provider profile for your Cortega endpoint. The example below permits a Node-based workload to reach a gateway over HTTPS. Replace the hostname and binary path with those in your deployment.
Example provider profile · YAML
id: cortega
display_name: Cortega Gateway
category: inference
inference_capable: true
credentials:
- name: gateway_key
env_vars: [CORTEGA_GATEWAY_KEY]
required: true
auth_style: bearer
header_name: authorization
discovery:
credentials: [gateway_key]
endpoints:
- host: gw.example.com
port: 443
protocol: rest
access: read-write
enforcement: enforce
binaries: [/usr/local/bin/node]Supply the real key to OpenShell’s credential source as CORTEGA_GATEWAY_KEY; do not write it into the profile or agent image. The attached provider supplies a placeholder to the workload and substitutes the credential on the authorized endpoint.
03
Attach the provider and configure the client.
Save the profile as cortega.yaml, lint and import it, then create the provider using the credential available to OpenShell. Attach it when starting the sandbox. Replace the example image with your own agent image.
OpenShell CLI · example names
openshell profile lint -f cortega.yaml
openshell profile import -f cortega.yaml
openshell provider create --name cortega --type cortega --from-existing
openshell sandbox create --name team-agent \
--from registry.example.com/team/agent:1.0 --provider cortegaIn the agent’s model client, set the base URL to your Cortega endpoint, such as https://gw.example.com/v1. Use the approved model alias and the credential variable supplied by the provider. Match the client API to the gateway and serving model.
04
Restrict other routes and connect tools.
Keep only the required destinations and binaries in sandbox policy. Remove unused direct model-provider routes and credentials. If the agent uses supported MCP tools, connect those through the Cortega MCP gateway and assign the required tool permissions. Local shell commands still use OpenShell and application permissions.
Check the setup
Verify the permitted and denied paths.
- Allowed model callA harmless request succeeds and appears in Cortega with the intended identity, team and serving model.
- Denied destination or modelAn unapproved destination is denied by OpenShell; an unauthorized model request follows the Cortega team’s configured denial or routing policy.
- Budget and stop behaviorVerify the configured budget boundary in a test workload. Revoke the Cortega key to deny new governed calls; stop the sandbox separately when you need to terminate execution.