Can a OpenAI Agents SDK agent run under your controls without rewriting it?
A team has an agent written in OpenAI Agents SDK. Before it touches customer data, the platform team wants it on the inventory, approved by a named reviewer, run as one step of a governed flow, with its tools reached through one gateway and its model calls screened and masked. The question is whether that means rewriting the agent.
It does not. The platform's controls apply to an endpoint, not to a framework. The Registry and the Orchestrator work on a contract: an endpoint that speaks REST, A2A or MCP, JSON in and JSON out. Flow Studio has no framework chooser.
The rest of this post is the OpenAI Agents SDK example from the container run, step by step, with its code. The overview of the series puts the five frameworks side by side.
1. Register the agent by its endpoint
The agent is registered in the Registry with a manifest: name, description, endpoint, version, protocol and capabilities, with input and output schemas. Registering it is enough for it to appear in Flow Studio's side panel. The example's manifest, with the endpoint as a placeholder:
POST /tenants/{tenant_id}/agents/register (multipart field: manifest)
{
"name": "OpenAI Agents SDK example agent",
"description": "A OpenAI Agents SDK agent that looks up a routing table through MCP tools behind the Gateway, with its model calls going through Kavach and Aavaran.",
"endpoint": "http://<agent-host>:8000/run",
"version": "0.1.0",
"protocol": "rest",
"capabilities": [
"mcp-tools",
"tool-use",
"kavach-shielded-model-calls"
],
"agentType": "agent",
"interface": "rest",
"category": "Framework examples",
"agent_metadata": {
"health_endpoint": "http://<agent-host>:8000/health",
"framework": "openai-agents"
},
"input_spec": {
"type": "object",
"required": [
"task"
],
"properties": {
"task": {
"type": "string",
"description": "What to ask the agent"
},
"task_class": {
"type": "string",
"description": "A task class to look up, such as bug-fix"
}
}
},
"output_spec": {
"type": "object",
"properties": {
"answer": {
"type": "string"
},
"tool_calls": {
"type": "array"
},
"model": {
"type": "string"
},
"shielded_by": {
"type": "string"
},
"entities_masked_count": {
"type": "integer"
}
}
}
}The author is set to the signed-in user. Headers an agent needs are kept in the Registry's encrypted store.
2. Submit it for approval, and approve it
Approval is a request per agent version, pending, then approved or rejected, with who submitted it and who decided. In the run, the agent was submitted and approved before the flow ran.
POST /tenants/{tenant_id}/agents/{agent_id}/submit-for-approval
POST /tenants/{tenant_id}/agents/{agent_id}/approval/{approval_id}/decide?decision=approveThe Registry records the decision and emits the audit events approval_submitted and approval_approved.
3. Serve it as a step: the contract
The Orchestrator calls a REST agent with POST and a JSON object, adding X-Tenant-Id, X-Agent-Id, X-Correlation-Id (the run's id) and X-Span-Id, and expects a JSON object back; an answer of 400 or more fails the step. Before a run it probes each endpoint with HEAD, then GET, and any answer under 500 passes. The agent's host must be public, or listed in AGENT_INTERNAL_HOSTS. The example serves the agent with a few lines of FastAPI:
# common/aa_examples/step_server.py (trimmed): the whole of what the platform asks of a REST agent
app = FastAPI(title=f"{framework} example agent")
@app.get("/health")
def health():
return {"status": "ok", "framework": framework}
@app.get("/run")
def probe():
# The Orchestrator probes with HEAD, then GET; any answer under 500 passes.
return JSONResponse({"detail": "POST a JSON object to this address."}, status_code=405)
@app.post("/run")
async def run(request: Request):
payload = await request.json()
ctx = RunContext.from_headers(request.headers) # X-Tenant-Id, X-Agent-Id, X-Correlation-Id, X-Span-Id
outcome = await execute(framework, run_agent, AgentRequest.from_payload(payload), ctx)
return JSONResponse(outcome.body, status_code=outcome.status)Drawn in Flow Studio, the OpenAI Agents SDK agent is the first step of a two-step flow; the second, the Text Insights sample agent, reads its answer.
4. Tools over MCP, through the Agent Universal Gateway
The agent's tool calls go to the Gateway's MCP route, with a Gateway API key in X-API-Key; the Gateway checks them and passes them over MCP to the agentanywhere-mcp server. Five questions to ask of an AI agent gateway explains what the Gateway checks. The OpenAI Agents SDK code:
# openai-agents/agent.py (trimmed)
import os
os.environ.setdefault("OPENAI_AGENTS_DISABLE_TRACING", "1")
from agents import Agent, OpenAIChatCompletionsModel, Runner, set_tracing_disabled
from agents.mcp import MCPServerStreamableHttp
from openai import AsyncOpenAI
set_tracing_disabled(True) # the SDK's own trace export is off: nothing is sent to its vendor
async def run_agent(req, ctx):
s = ctx.settings
client = AsyncOpenAI(base_url=s.llm_base_url, api_key=s.llm_api_key,
default_headers=ctx.llm_headers(), max_retries=0)
# Tools over MCP, through the Gateway; its API key travels in X-API-Key.
async with MCPServerStreamableHttp(name="agentanywhere",
params={"url": s.mcp_url, "headers": s.gateway_headers(), "timeout": 30},
cache_tools_list=True) as server:
agent = Agent(name="router_table_agent", instructions=INSTRUCTIONS, mcp_servers=[server],
model=OpenAIChatCompletionsModel(model=s.llm_model, openai_client=client))
result = await Runner.run(agent, req.prompt())In the run the agent called the taksha_router_table tool through the Gateway.
5. Model calls behind Kavach and Aavaran
The agent's model client points its base URL at Kavach, which is OpenAI chat-completions compatible. Kavach screens the request for injection, has Aavaran mask personal data, calls the model, checks the answer and keeps an audit line; tool calls pass through. In the run, Kavach's audit lines recorded 4 entities masked, and neither the e-mail address nor the PAN in the request reached the model server. Masking before the model is one of the safeguards the DPDP Rules name.
# openai-agents/agent.py: the SDK's chat-completions model class, with a client pointed at Kavach
client = AsyncOpenAI(base_url=s.llm_base_url, api_key=s.llm_api_key,
default_headers=ctx.llm_headers(), max_retries=0)
model = OpenAIChatCompletionsModel(model=s.llm_model, openai_client=client)The SDK's own tracing is switched off twice, by `OPENAI_AGENTS_DISABLE_TRACING=1` and `set_tracing_disabled(True)`, so the run's record stays in the platform and in Observe. X-User-Id carries the run's id, so the run can find Kavach's audit lines; nothing personal.
Where the settings come from
Every address and key is read from the environment, so the same image runs in any stack. These are the values the local stack used; the key is a placeholder.
# The example reads everything from the environment, so the same image runs in any stack.
LLM_BASE_URL=http://kavach:8787/v1 # Kavach; Aavaran's proxy is http://<aavaran>:8080/v1/proxy
LLM_MODEL=<model-name>
MCP_URL=http://gateway:8000/mcp # the Gateway's MCP route
GATEWAY_API_KEY=${GATEWAY_API_KEY} # a Gateway API key, sent as X-API-Key
AGENTOBS_BASE_URL=http://observe:8090 # Observe6. What the run leaves: an evidence pack and an Observe trace
The Orchestrator keeps an evidence pack for every run, built only from what it recorded: each step's status and output, the agent, the model and the mask it reported, approvals. This excerpt is real output from the container run, with ids shortened:
{
"kind": "agentanywhere.evidence-pack",
"run": {
"run_id": "usecase-13-8564f73b…",
"status": "success"
},
"steps": [
{
"agent_name": "OpenAI Agents SDK example agent",
"status": "success",
"model": {
"provider": "kavach",
"model": "stub-model",
"shielded_by": "Kavach",
"kavach_record": "4258814b…"
},
"masking": {
"method": "irreversible",
"policy_id": "default-shield",
"entities_masked_count": 4
},
"output": {
"framework": "openai-agents",
"framework_version": "0.24.0",
"tool_calls": [
{
"name": "taksha_router_table",
"arguments": {
"task_class": "bug-fix"
}
}
],
"shielded_by": "Kavach",
"entity_types": [
"email",
"pan"
],
"entities_masked_count": 4
}
},
{
"agent_name": "Text Insights",
"status": "success"
}
],
"audit_events": null,
"audit_events_note": "The audit trail could not be read for this request."
}The audit_events note is there because the audit service was not part of the run (see below).
When Kavach refuses the call
A second run sent a real injection. Kavach refused the model call, the agent answered HTTP 403, and the step failed with Kavach's reason in the evidence pack. Real output from the container run:
{
"run": {
"status": "error"
},
"steps": [
{
"agent_name": "OpenAI Agents SDK example agent",
"status": "error",
"error": "AgentHttpError: The agent answered HTTP 403: The model call was refused by Kavach (prompt_injection). ML injection classifier fired (label=INJECTION, score=0.985); Canonical attack phrasing matched"
}
]
}The Observe trace
The example opens a run record in Observe with its SDK, under the platform's run id, and passes on what Kavach's audit lines said. Real output from the container run, ids shortened:
{
"correlation": {
"run_id": "usecase-13-8564f73b…",
"agent_slug": "example-openai-agents",
"status": "completed"
},
"trust_summary": {
"events": 3,
"kavach": {
"allow": 2,
"block": 0,
"flag": 0
},
"veil": {
"passes": 1,
"entities_masked": 4,
"entity_types": [
"email",
"pan"
]
}
}
}What this does not show
No real model. The model was a stand-in server. Nothing here shows what a real model does with masked text or with tool results.
No audit service. The audit service was not part of the run, so the evidence pack's audit_events field reads "The audit trail could not be read for this request."
No Agent Lab checks. The credentials, personal-data, injection, soak and health checks need Agent Lab's runner, which was not part of the run.
No A2A. The OpenAI Agents SDK has no A2A support (there is an open feature request upstream), so this agent is a REST step only.
One environment per framework. The example has its own environment and image, pinned to openai-agents 0.24.0, which needs openai 3.x, on Python 3.11. The frameworks' dependencies conflict (for example, mcp 2.x, which LangChain's MCP client uses, cannot share an environment with Microsoft Agent Framework, which caps it below 2), so each runs alone.
The platform's local stack. Every service ran in a container on a rented machine, with an in-memory workflow server. It is the platform's local stack, not a production deployment.
No Semantic Kernel. Semantic Kernel has no example: Microsoft names Agent Framework its successor.
Frequently asked questions
Can a OpenAI Agents SDK agent run inside AgentAnywhere without changing the platform?
Yes. A OpenAI Agents SDK agent served as a REST endpoint is registered in the Registry by its endpoint, approved, and placed in a flow as a step; no platform code changes. This was shown in a container run on 21 October 2026, with a stand-in model.
How does a OpenAI Agents SDK agent call MCP tools through the AgentAnywhere Gateway?
With the SDK's MCPServerStreamableHttp, its params carrying the URL of the Gateway's MCP route and the Gateway's API key in X-API-Key. The Gateway routes the calls over MCP to the MCP server.
How are a OpenAI Agents SDK agent's model calls screened and masked?
The SDK's OpenAIChatCompletionsModel uses an AsyncOpenAI client whose base_url points at Kavach, which is OpenAI chat-completions compatible. Kavach screens each call for injection, has Aavaran mask personal data, then calls the model; a blocked call returns HTTP 403 and the step fails with that reason.
Does the OpenAI Agents SDK send traces to its vendor here?
No. The example sets OPENAI_AGENTS_DISABLE_TRACING=1 and calls set_tracing_disabled(True), so the SDK's own trace export is off. The run is recorded in the platform's evidence pack and in Observe.
What does the platform record when a OpenAI Agents SDK agent runs?
An evidence pack per run, with each step's status and output, the agent's name, the model and the masking Kavach reported, and approvals; and, through Observe's SDK, a run record with Kavach's allow and block verdicts and the entities masked.
Sources
Vendor documentation read on 21 October 2026; the example's code is in agentanywhere-examples, which has no public repository yet.
Written by
AgentAnywhere Research
The team that builds the platform and the models
AgentAnywhere Research writes about the platform, the model families and the trust layer we build and run in India. Where a figure is ours, it says what it covers; where something is a demonstration, it says so.
