Production-Ready Agent Behavior: Identity, Intent, and Governance

oso · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Runtime governance and authorization for production AI agents

Oso argues that production agents need identity, intent filtering, and runtime governance because they call real backend services, can read untrusted content, can access sensitive data, and behave nondeterministically in ways that pre-production tests cannot exhaustively cover.

Constraints:

• Agents may need permissions different from the user they represent.
• Authorization must account for user, agent, and session context, not just a user credential.
• Prompt injection and intent drift can cause agents to combine sensitive data access with external communication.
• Security-critical guardrails should be deterministic code policies rather than prompts or LLM-judge decisions.

Architecture

Oso wraps LangChain 1.0 agents with middleware that calls Oso for real-time authorization decisions. A three-part identity model captures user(s), agent, and session, while the session tracks facts such as untrusted-content access and sensitive-data access. Wrap model call filters irrelevant tools before the LLM chooses an action; wrap tool call blocks dangerous executions and returns contextual denial messages. The monitoring dashboard logs decisions, supports quarantine, disables tools dynamically, and separates policy definition from middleware enforcement.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  user-request["User request"] --> langchain-agent["LangChain agent"]
  langchain-agent["LangChain agent"] --> wrap-model-call-middleware["Wrap model call middleware"]
  langchain-agent["LangChain agent"] --> wrap-tool-call-middleware["Wrap tool call middleware"]
  langchain-agent["LangChain agent"] --> backend-tools["Backend tools"]
  wrap-model-call-middleware["Wrap model call middleware"] --> oso-authorization-service["Oso authorization service"]
  wrap-model-call-middleware["Wrap model call middleware"] --> backend-tools["Backend tools"]
  wrap-tool-call-middleware["Wrap tool call middleware"] --> oso-authorization-service["Oso authorization service"]
  wrap-tool-call-middleware["Wrap tool call middleware"] --> backend-tools["Backend tools"]
  oso-authorization-service["Oso authorization service"] --> session-fact-store["Session fact store"]
  session-fact-store["Session fact store"] --> policy-definitions["Policy definitions"]
  policy-definitions["Policy definitions"] --> oso-authorization-service["Oso authorization service"]
  oso-authorization-service["Oso authorization service"] --> agent-monitoring-dashboard["Agent monitoring dashboard"]
  policy-definitions["Policy definitions"] --> agent-monitoring-dashboard["Agent monitoring dashboard"]

Components

Data flow

A user request enters a LangChain agent registered with Oso middleware. Before model selection, wrap model call can remove tools that do not match the user's intent or permission context. If the agent later attempts a tool call, wrap tool call sends the user, agent, session, requested tool, and accumulated session facts to Oso. Oso evaluates policies such as blocking external communication after both untrusted content and private data were accessed, returns a denial or allow decision, and logs the event for monitoring, quarantine, or tool disabling.

Why this architecture

The architecture separates policy from agent reasoning because prompts cannot reliably enforce security boundaries. Session state lets policies reason over dangerous sequences rather than isolated actions. Wrap model call provides proactive tool attenuation for intent alignment, while wrap tool call provides reactive blocking for security-critical execution. The dashboard closes the loop with production quarantine and tool disablement without code deployment.

Models used: LangChain 1.0 agent models · LLM-as-judge for intent-based tool filtering · OpenAI models

Scale

• The presentation is based on approximately the past year of Oso helping customers productionize agents.
  “The talk is rooted in real-world experience helping customers productionize agents over approximately the past year”summary, stated
• The framework defines three productionization stages: prototype to QA, QA to production, and running in production.
  “Vijay organizes the productionization journey into three distinct stages, each with unique challenges that are specific to agents rather than traditional software systems:”summary, stated
• The identity model has three components: user(s), agent, and session.
  “proper agent authentication requires three distinct components: user(s), agent, and session.”summary, stated
• The demo agent uses three tools: feature-request query, SQL execution, and comment posting.
  “The live demonstrations use a fictional product management portal agent with access to three tools: querying feature requests, executing SQL queries, and posting comments”summary, stated
• The talk frames 2025 as analogous to 1997 for prompt injection.
  “what 1997 was for SQL injection, 2025 is for prompt injection.”summary, stated

Alternatives considered (roads not taken)

Passing only user identity to backend services

Rejected because: Agents may need elevated capabilities users lack, or restrictions users do not have, so user identity alone is too coarse.

Prompt engineering alone for prompt injection defense

Rejected because: New models quickly get exploited and clever prompts can bypass behavioral instructions.

Blocking every bad tool call only after the agent chooses it

Rejected because: Reactive blocking creates awkward denial/retry loops when tools could have been hidden before model selection.

Comprehensive pre-production testing as the main safety strategy

Rejected because: Agent interactions are nondeterministic and every interaction can become an edge case.

Patterns

safety-policy-enforcement (governance)

Oso enforces deterministic authorization rules around model and tool calls, including session-taint policies that block exfiltration paths.

tool-use-orchestration (architecture)

LangChain middleware shapes which tools are available to the model and whether selected tools are allowed to execute.

observability-tracing (operations)

The monitoring dashboard logs tool calls, denied actions, reasons, and filtered tools so operators can audit and respond to behavior.

human-in-the-loop-gate (governance)

Security teams or product managers can quarantine agents or disable tools at runtime without engineering deployment.

context-engineering (context)

Oso treats the session's persistent context and tainted facts as governance-critical inputs, not just conversational memory.

Tradeoffs

Use deterministic authorization for security

Chose Code-level session-aware rules over Prompt-only defense or LLM-judge prompt-injection detection.

Rationale: Security policies must hold even when the model is confused or adversarially prompted.

Filter tools before the model when possible

Chose Wrap model call attenuation over Letting the model choose every tool and blocking later.

Rationale: Proactive filtering keeps the agent focused on user intent and avoids denial/retry loops.

Add an external authorization service and middleware

Chose Oso service plus LangChain middleware over Embedding all policy logic directly in prompts or agent code.

Rationale: Separating policy from enforcement lets non-engineers adjust runtime policies and creates centralized visibility, at the cost of additional components and latency.

Shift from prevent-all testing to runtime governance

Chose Monitor, quarantine, alert, and dynamically disable tools in production over Relying on QA and pen testing to cover all agent edge cases.

Rationale: Agents are nondeterministic and every interaction may be an edge case, so teams need rapid detection and mitigation.

Gotchas (what bit them)

User identity alone can authorize the wrong thing.

Root cause: Agents may need capabilities users lack, while other actions should be forbidden to agents even if the user could do them directly.

Resolution: Use a three-component identity model covering user(s), agent, and session.

Prompt injection can exploit accumulated session context.

Root cause: An agent can read untrusted instructions, query sensitive data, and later attempt external communication in the same context window.

Resolution: Track session facts and block external communication when untrusted content and private data have both been accessed.

LLM-as-judge is not reliable enough for security-critical decisions.

Root cause: Intent judgments are nondeterministic and may miss zero-day prompt injection or produce false positives/negatives.

Resolution: Use LLM-as-judge only for intent-based filtering, and deterministic rules for hard security boundaries.

Reactive blocking alone creates poor agent behavior.

Root cause: If the model sees irrelevant tools, it may repeatedly choose blocked actions and then handle denial messages awkwardly.

Resolution: Filter tools before model calls when intent makes a tool irrelevant.

Production agents need fast mitigation after deployment.

Root cause: Nondeterministic behavior makes comprehensive pre-production coverage impossible.

Resolution: Provide real-time monitoring, quarantine, tool disabling, and alert integration.

Evaluation

Oso evaluates and governs behavior through runtime logs of allowed/denied tool calls, filtered tool sets, reasons for denials, alerting, quarantine, and operator-driven policy changes rather than relying only on pre-production QA.

Metrics: tool calls · denied actions · reasons for denial · filtered tools · misbehaving-agent alerts · quarantine actions · disabled tools · audit attribution by user/agent/session

Outcomes

• The demo blocks a data-exfiltration path when a session has touched both untrusted content and sensitive data.
• Intent-based attenuation removes SQL and comment-posting tools when the user only asks for backlog requests.
• Operators can quarantine a misbehaving agent or disable tools without code changes.
• The case provides a concrete runtime-governance architecture for production agents.

The scale context is mostly operational rather than traffic-based: three production stages, three identity dimensions, three demo tools, real-time API authorization, and no-code quarantine/tool-disable controls.