Without Gateway
Provider data fragments.
Usage, cost, retries, errors, cache behaviour, and model activity live across separate provider dashboards, accounts, API keys, and logs.
§ 01Model access at scale
Model calls are easy to start.
They become hard to control at scale.
A team can start with one provider key and one model call. Then the usage spreads: different apps, agents, scripts, tools, accounts, dashboards, providers, and teams. Soon nobody has a single view of what was called, what it cost, which workflow caused it, or whether the call should have continued.
Gateway gives provider access one operating layer. It consolidates model traffic, provider context, usage data, retry behaviour, and control state before the organisation loses visibility across disconnected integrations.
That makes model access easier to operate, measure, and control as AI usage moves from experiments into production workflows.
With Gateway
Provider traffic becomes accountable.
Gateway creates one operating layer for provider access, model usage, context, cost visibility, retries, and run outcomes.
With Sentinel
Execution can be controlled.
When Sentinel is enabled, Gateway hands the request into PriviShield and Sentinel Edge for screening, verdicts, redaction, review, block, and receipt-backed evidence.
§ 02Operating context
Gateway connects model calls to people,
teams, and the workflows behind them.
Provider dashboards can show activity inside their own boundary. They usually cannot explain how that activity maps back to your organisation: tenant, department, team, user, role, workspace, project, workflow, app, service, agent, provider, and model.
Gateway sits at the provider access point so every model call can carry the operating context needed to make usage, cost, retries, latency, response status, and control state understandable.
Calling context
Who created the call
Gateway can attach organisation, tenant, workspace, project, workflow, service, app, agent, user, role, and channel context where available. Operators get an internal owner for provider usage instead of a disconnected provider-side line item.
Provider and model
Which provider and model were used
Gateway resolves the provider and model selected for the request. Teams can understand which models are being used, by whom, and for which workflow without spreading provider logic across every application.
Model and provider catalog
Which models are approved
Gateway can maintain approved provider and model options so teams can connect applications and agents to the right models without hard-coding provider choices into every runtime. Platform teams get a place to manage model availability and provider changes as the market shifts.
Credential context
Which credentials and channel were used
Gateway attaches provider authentication, credential, channel, and tenant context to the call. Depending on provider support and deployment design, that may involve OAuth where supported, API-key access where required, token-based access where supported, tenant-bound channels, or customer-managed credential paths.
Control handoff
When safety control is required
Gateway can hand provider-bound traffic into PriviShield and Sentinel Edge when sensitive-data screening, redaction, review, block, or policy enforcement is required. Operators can see when model access moved from telemetry into control.
Telemetry and outcome
What telemetry explains the run
Gateway can produce the usage and provider telemetry needed to explain model activity: agent reference, tenant context, provider, model, timestamp, latency, retry state, response status, workflow context, Sentinel handoff state, and control result where available.
§ 03Usage intelligence
Provider dashboards show fragments.
Gateway consolidates the data.
Model providers report usage through their own dashboards, token categories, account boundaries, cache rules, retry behaviour, and billing exports. Gateway connects those fragments back to your own operating structure: tenants, departments, teams, users, roles, workspaces, projects, workflows, agents, providers, models, retries, latency, and results.
That turns model usage from provider-side billing fragments into an operating ledger.
Cost by provider
Provider spend by access point.
Break down spend across provider access points so teams can compare where model usage is actually going.
Cost by model
Model accountability.
Separate model usage by provider, model family, and operating context instead of relying on provider dashboards with different reporting shapes.
Token and cache breakdown
Token categories where available.
Track input tokens, output tokens, cache read, cache write, and provider-specific token categories where available.
Retry and failure cost
Hidden cost made visible.
Retries, failed calls, timeouts, and repeated attempts can quietly inflate spend. Gateway can attach those costs to the workflow or agent that caused them.
Workflow and project attribution
Filter by internal owner.
Filter usage by organisation, tenant, department, team, user, role, workspace, project, workflow, app, service, or agent where context is available.
Completed job view
Cost per completed task.
The useful question is not only “how many tokens were used?” It is what the completed task cost, how many retries it required, and whether the model choice was worth it for that capability.
Token price is only the raw ingredient. Gateway helps teams understand the real operating cost: cost per completed task, cost per workflow, cost per capability, retry cost, failure cost, and model cost by provider, project, team, and agent.
§ 04Model provider layer
Agents and AI applications call Gateway.
Gateway handles the model provider layer.
Agents, AI applications, copilots, tools, and workflows should not each rebuild their own provider integration, credential handling, usage tracking, retry logic, and control handoff. Gateway gives them one model provider layer to call.
01
Agent / AI App / Workflow
02
Aera Gateway
03
Provider and model context
04
PriviShield / Sentinel
when enabled
when enabled
05
Model provider
06
Response and usage record
Gateway gives teams one model provider layer instead of asking every agent, AI application, copilot, tool, and workflow to rebuild credential handling, usage tracking, retry logic, and provider telemetry.
With Sentinel enabled, the same operating layer becomes the handoff point for sanitisation, policy evaluation, verdicts, and receipt-backed evidence.
§ 05Capability layers
Start with model access visibility.
Add protection as the risk grows.
Gateway should be valuable on its own: model access, provider routing, usage reporting, cost visibility, provider telemetry, retries, latency, and response records.
Vault, PriviShield, and Sentinel add deeper protection to that same operating layer. Vault protects execution rights. PriviShield reduces sensitive-data exposure. Sentinel controls execution decisions across the runtime.
Gateway
Model access and usage visibility
Unifies provider-bound traffic, model routing, provider telemetry, usage records, cost visibility, retries, latency, and response continuity.
Gateway + Vault
Execution rights protection
Adds protected credential access so agents and workflows can request use of a capability without placing raw secrets, API keys, tokens, or OAuth grants into model context.
Gateway + PriviShield
Sensitive-data exposure protection
Adds provider-bound and return-path screening for PII, secrets, credentials, unsafe prompt material, and sensitive content before it reaches the model or returns to the agent.
Sentinel bundle
Execution control
Adds PriviShield, Vault, Sentinel Edge, pathway and surface evaluation, temporal trajectory, verdicts, redaction, review, block, and receipt-backed evidence across the runtime.
Gateway unifies the model-provider access and usage layer. Vault, PriviShield, and Sentinel add protection where credentials, sensitive data, and runtime decisions need stronger control.
§ 06Operating control
Model access becomes infrastructure
once teams depend on it.
Once agents and AI workflows move into production, model calls are no longer experiments. They become operating infrastructure. Gateway gives teams a place to measure, attribute, control, and explain that usage across providers, models, teams, users, projects, workflows, retries, and outcomes.
Security
Screen before exposure.
Provider-bound traffic can be screened before exposure and checked again when responses return.
Audit
Explain what happened.
Usage and provider telemetry help explain which system called which model, under which context, with what result.
Cost visibility
See what the work costs.
Gateway connects spend to the tenant, team, user, project, workflow, model choice, retry state, and outcome that created it.
Deployment hygiene
Stop rebuilding provider logic.
Teams can connect agents and applications through one model access layer instead of spreading provider logic across every runtime.
§ 07Bidirectional control
Control has to work both ways.
Requests go out. Responses come back.
Provider-bound requests can expose sensitive data or unsafe instructions. Provider responses can return unsafe code, tool instructions, injected content, or behaviour that should not re-enter the agent context unchecked.
Gateway keeps the outbound request and inbound response attached to the same operating record. That record can include response status, latency, retry state, failure recovery, usage, estimated cost, and control result.
When Sentinel is enabled, the return path can be evaluated before the response re-enters the agent or workflow.
Return 01
Request leaves
The outbound call carries provider, model, and operating context.
Return 02
Provider responds
The model provider returns output, status, usage, and timing signals where available.
Return 03
Gateway records
The response stays attached to the same operating record.
Return 04
Sentinel checks when enabled
The response can be evaluated before continuation.
Return 05
Agent or workflow continues
The agent or workflow receives the response after the required control step.
§ 08Deployment shapes
Gateway fits the deployment shape.
Cloud, local, or customer-managed.
Gateway can sit where model provider access best fits the team’s deployment boundary: close to local builders, inside customer-managed infrastructure, or as hosted Aera-managed infrastructure.
Local / desktop
Close to local builders.
For local builders and desktop-first deployments, Gateway can sit close to the agent environment and local model-provider workflows.
Customer-managed
Inside the customer boundary.
For enterprise environments, Gateway can be deployed inside the customer’s infrastructure boundary where provider telemetry, evidence, and operational controls stay aligned with customer requirements.
Aera-managed
Hosted model access.
For teams that want hosted infrastructure, Aera-managed Gateway can provide managed model provider access while preserving tenant policy boundaries.
§ 09Telemetry and evidence
Gateway records
Provider telemetry.
Sentinel records
Control evidence.
Gateway makes model provider activity explainable: who called, what model was used, what it cost, how long it took, whether it retried, whether it failed, and which workflow, project, team, or agent created the run.
When Sentinel is enabled, that provider telemetry can be paired with verdicts, policy references, pathway and surface labels, redaction state, receipts, and replay evidence.
Gateway evidence should explain model provider activity: which agent or service made the call, which provider and model were used, when it happened, how long it took, whether it retried, and whether it failed.
Provider telemetry can also attach usage context where available: tokens, cache behaviour, retry count, failure state, estimated cost, completed run, workflow, project, and team attribution.
When Sentinel is enabled, the same record can be paired with control evidence: verdicts, policy references, pathway and surface labels, redaction state, receipts, and replay references.
Provider telemetry record
illustration only
Provider telemetry
agent_refagent.ops.assistant
gateway_recordgw-record-7f42
providerprovider.primary
modelmodel.reasoning.large
workflow_refworkflow.release-review
completed_run_refrun.demo.118
Usage
input_tokens18,420
output_tokens2,180
cache_read12,900
cache_write4,200
retry_count1
failure_staterecovered_timeout
Cost and ownership
estimated_cost$0.42
team_refteam.platform
project_refproject.gateway-rollout
channeldesktop-runtime
pathwayprovider call
latency842ms
Control
sentinel_handoffenabled
verdictreview
receipt_refrcpt.demo.019
Illustration only. Shows provider telemetry, usage, cost, and control evidence metadata without implying raw prompt or response storage by default.
Put model provider access under control.
Gateway brings provider access, usage, cost, retry, and outcome data into one operating layer. Sentinel adds runtime control. Vault protects execution rights. Together they turn scattered model infrastructure into an accountable AI operating path.