The Other Half of Agent Trust. Agent Stream Is Live

AI agents are moving from experiments into real business workflows

They retrieve information, call tools, query databases, communicate with other agents and take action on behalf of people and organisations. A single task can cross multiple models, providers and systems before an answer or action reaches its destination.

That creates a new kind of trust problem.

Before an agent is allowed into a system, you need to know who it is, who or what it represents and what it is authorised to do.

But identity at the point of entry is only the first half of agent trust.

Once an agent has been authenticated, another set of questions begins:

• Which model should handle its request?

• What tools and data can it use?

• Is the interaction still within policy?

• Is the model output safe and appropriate?

• What happens if a provider fails?

• Can operators see and influence what is happening as the agent runs?

Identity alone cannot answer these questions. They require governance throughout execution.

That is why we built Agent Stream, now live as part of the Affinidi Trust Fabric.

Adoption is outrunning the controls meant to govern it.

Enterprises are not waiting to find out if agentic AI works they’re deploying it now, faster than most security and governance functions can keep pace with. Analysts expect roughly 40% of enterprise applications to incorporate task-specific AI agents by the end of this year, up sharply from a year ago. But scale has arrived well ahead of control: in one recent industry survey, 92% of organizations said governing AI agents is critical to enterprise security, while nearly a quarter reported an agent had already been manipulated into revealing access credentials. Security professionals increasingly agree - in a recent Dark Reading poll, agentic AI and autonomous systems ranked as the single biggest attack vector heading into this year, ahead of deepfakes and passwordless adoption. And in a separate 2026 survey, the majority of organizations reported at least one confirmed or suspected AI agent security incident in the past year.

The pattern echoes what security teams saw with fraud and malware attackers adapting continuously, defenses lagging behind, but the mechanics are different. A jailbreak or prompt-injection technique that works today can be patched tomorrow and re-emerge in a new form the day after. Every new tool, data source or downstream agent an application wires in expands the surface an attacker or a misconfigured workflow can reach. And the regulatory response is intensifying too: frameworks like the EU AI Act and a wave of sector-specific AI governance requirements are stacking new compliance obligations on top of existing data-protection law, often faster than internal policy can be rewritten to match. Traditional, perimeter-based defenses were built for systems that don’t act on their own. Agents do and they do it at machine speed, which means the controls have to run at that speed too.

Cost adds a second, quieter pressure. A growing number of companies want every employee to benefit from AI, but as adoption increases, many organizations are concerned that AI infrastructure costs will grow too quickly. Costs scale with the amount of context, documents, and retrieved information sent to large language models. Sending more information can improve the quality and relevance of responses, but it can also increase token usage, latency, and cost while reducing the information sent to the model may lead to less accurate or less useful responses. Without a governance layer sitting between applications and models, that trade-off gets made ad hoc, application by application, with no consistent way to see or control the spend.

And most of the risk that does materialize doesn’t come from the model itself, it comes from how it’s deployed. Per OWASP’s GenAI LLM Top 10, the real threats are prompt injection, PII leaks, system-prompt extraction, unsafe outputs, and inconsistent moderation spanning development, deployment, and runtime. Model-level safety alone can’t catch this: it doesn’t see how your application builds prompts, what data it retrieves, or what your organisation’s policies require.

Audit logs explain what happened. Runtime governance can influence what happens next.

Traditional software governance often depends on what happens after an event.

A system records a request. An application generates a log. A dashboard surfaces an anomaly. Someone investigates the incident, reconstructs what happened and updates a rule to reduce the chance of it happening again.

That approach is valuable for accountability, but it is not enough for autonomous systems.

AI agents can make decisions and take action at machine speed. They can dynamically choose tools, generate queries, retrieve sensitive information, and pass outputs to another agent or service. A problematic interaction may move through several systems before a conventional monitoring workflow identifies it.

By the time an audit log tells you what happened, the unsafe output may already have been generated. Sensitive information may already have been disclosed. The wrong tool may already have been called. An action may already have been completed.

The problem is not that audit logs are unnecessary. Agentic systems still need attribution, traceability and reliable records. The problem is that retrospective evidence cannot be the only form of governance.

A flight recorder can help explain an accident. It cannot steer the aircraft away from danger.

Agent governance needs to operate while the interaction is happening.

It must evaluate each request against the relevant context and policy, apply the right safeguards, route the request to an appropriate destination and respond when conditions change.

That requires a shift from observing execution after the fact to governing execution in the flow.

Governance that moves at the speed of the agent

Agent Stream introduces a control layer for the execution path itself.

Instead of requiring every team to build separate integrations and controls for each model, tool or database, Agent Stream provides a unified layer through which agentic workloads can be managed.

This creates a consistent place to evaluate, route and safeguard interactions as they happen.

Continuous evaluation

An agent interaction is not a single, static event.

Context changes as a workflow progresses. An agent may receive new information, call another service or produce an output that changes what should be permitted next.

A request that appears acceptable at the start may become risky when additional context is introduced. An output may be relevant but contain information that should not be shared. A tool call may be valid for one agent, user or task but inappropriate for another.

Agent Stream evaluates interactions at governed points throughout the execution pipeline, including request handling, routing, provider execution, tool use where configured, and response validation.

This makes configured policy and safeguards part of the execution path.

Controls can be applied where decisions are being made, not added later as a separate compliance exercise. Teams gain a way to govern agent behavior throughout the workflow, including the inputs agents receive, the providers they access and the outputs they produce.

Continuous evaluation also helps organisations respond to changing conditions. If the context, risk level or intended action changes, the governing policy can be applied at the point where it matters.

Intelligent routing

Most organisations will not build their agentic systems around a single model or provider.

Different models perform better for different tasks. Some workloads may prioritise reasoning quality, while others need lower latency or greater cost efficiency. Certain data may also need to remain within a particular provider or environment.

Without a shared execution layer, teams have to manage this complexity inside individual applications. They create provider-specific integrations, build their own fallback logic and manually update workflows when requirements change.

Agent Stream provides one layer for routing calls across models and providers. Routing can become an operational and governance decision rather than something permanently embedded in application code.

A request can be directed according to the policies and conditions relevant to that interaction. If a provider becomes unavailable, the workload can be rerouted. If different models are appropriate for different data classifications or use cases, those requirements can be reflected in the execution flow.

Teams gain flexibility without giving up control.

Built-in policy and output integrity

Agentic workflows introduce risk at multiple points.

A user can submit a malicious instruction. An agent can attempt to access a tool beyond its authority. Retrieved information can influence later decisions. A model can produce an unsafe or non-compliant output. A chain of individually acceptable actions can create an unacceptable result.

Protecting only the external boundary leaves too much activity ungoverned.

Agent Stream applies safeguards within the flow, helping enforce policy, safety and output integrity at each step.

This places controls closer to the behaviour they are intended to govern. Rather than expecting every application team to implement the same protections independently, safeguards can be applied through a shared execution layer.

The result is not simply more monitoring. It is the ability to influence what happens next.

What is Agent Stream?

Agent Stream is part of the Affinidi Trust Fabric: a suite of products, services and tools that help you identify, manage, govern, audit and control AI agent and AI-adjacent traffic across your ecosystem, inside your organisation, across organisations, and across clouds.

Technically, Agent Stream is an intercepting proxy purpose-built for managing the safety and governance of LLM service traffic. It sits between your AI resources (such as LLMs) and your agents, applying policy evaluation, guardrails, cost and usage governance, and observability to every call your agent makes to dependent services without requiring you to rewrite the AI applications or agents that call the models.

With Agent Stream, teams get AI-specific capabilities such as multi-provider LLM access through a single OpenAI-compatible interface, layered guardrails and content safety, LLM-as-judge and LLM-as-jury reasoning-based review, intelligent content-based routing, parallel-run LLMs for comparison and aggregation, exact and semantic response caching, per-team and per-member cost attribution, secrets and API key management, and prompt template management — all governed by policies derived from identity provider integrations like Entra and Okta. It’s paired with more traditional network-management capabilities: cross-provider failover, weighted and latency-based load balancing, circuit breakers, retry policy, rate limiting, key management, real-time monitoring, and enterprise integrations.

Agent Stream scales from a single team routing one application to one LLM provider, up to complex, multi-provider, multi-tenant architectures where dozens of teams, hundreds of agents and thousands of end users share a governed pool of models under central budgets, safety controls and audit.

Surfaces are central to how you manage all of this. A Surface is a mental model for a single, governed connection through the appliance. The core surface type is the LLM Surface, which fronts one LLM provider and carries the full pipeline of guardrails, routing, resilience, cost governance and observability. The complementary IDE Surface aggregates one or more LLM Surfaces into a governed model-discovery menu that IDE clients (VS Code / GitHub Copilot Chat, JetBrains, Continue, Eclipse) and any OpenAI-compatible agent can reach under a single Access Point. New Surface types covering other dependencies, such as memory and data stores, are on the roadmap.

You build Surfaces interactively, dragging and dropping components onto the canvas, adding a prompt guard element to redact or block sensitive patterns before a request reaches the model, configuring an Expert Witness element to consult a purpose-trained safety classifier such as EnkryptAI, Lakera Guard or Azure Prompt Shields, and adding a judge or jury element for reasoning-based review. Surfaces can also be configured directly in JSON for developers, with a CLI/SDK for automated, reproducible deployment on the near-term roadmap.

Agent Stream supports enterprise integrations via OpenTelemetry for metrics, logs and traces; native Langfuse export for LLM traces and generations; a Prometheus scrape endpoint; and delivery channels for email, Slack, generic webhooks, and streaming buses like Kafka, Kinesis, Pulsar and Redis Streams. It ships as a single Rust binary with no external database, cache or broker required, and is delivered as a fully managed Affinidi-hosted service.

You connect to Agent Stream through your browser, authenticating with Passkey or SSO via SAML (e.g. Azure AD for enterprise deployments), through a single-pane-of-glass interface.

---

Agent Gateway establishes trust at the edge. Agent Stream maintains integrity in the flow.

The two halves of agent trust are now coming together.

Explore Agent Stream at https://www.affinidi.com/agent-stream