Securing AI Agents: Why One Vendor's Guardrails Aren't

By Lazar Milicevic · Published October 19, 2026 · 10 min read

You shipped an agent that reads email, touches your CRM, and calls a few MCP tools. The built-in guardrails are switched on, and you're not sure if that counts as "secured." A recent VentureBeat survey suggests a lot of larger companies are in the same spot, and that leaning on one vendor's guardrails correlates with feeling more exposed, not less.

This post walks through what the survey actually says, what it doesn't, and a layered control stack you can build this week without an enterprise security budget.

What the VentureBeat survey actually found

The headline: organizations whose primary agent security layer is OpenAI's guardrails are more likely to say attackers are ahead of their defenses. The numbers are narrower than the headline suggests, so read them carefully.

VentureBeat Intelligence surveyed respondents at organizations with 100 or more employees in August 2026, with a base of 137 qualified respondents (VentureBeat). The key figures:

Across all August respondents, 34% said attackers and defenders are roughly even, 22% said their defenses are ahead, 21% said attackers are ahead, and 17% answered "don't know."

The 43% vs 16% gap is about 2.7x, which is where "nearly three times" comes from.

What the data does not say

Before anyone repeats "OpenAI guardrails make you less safe," note what VentureBeat itself says about the limits:

• The survey measured what respondents believe about attackers, not how exposed each organization actually is.
• VentureBeat says it cannot tell why OpenAI-reliant organizations are more likely to say attackers are ahead.
• Incident and near-miss rates for the two groups were too close to call.
• The groups are small: 42 and 64 respondents.

So there are several plausible readings, and the data can't separate them. Teams that adopt vendor guardrails may be earlier in their agent rollouts and more aware of the gaps. Teams that feel exposed may reach for the nearest built-in option. Or the perception may reflect something real about relying on a single layer. I can't tell you which, and neither can the survey.

There's also an applicability caveat: this is an enterprise survey (100+ employees). If you run a 3-person shop, treat it as a signal about where the industry is, not a measurement of your risk.

What is solid, and doesn't depend on the OpenAI-specific comparison:

1. Nearly everyone uses a big platform vendor as their primary layer, and almost nobody uses specialist security tooling (99% vs about 1%).
2. A majority of organizations running agents report an incident or near-miss (59%).
3. Credential sharing among production agents is common (62%), and isolation of high-risk agents is rare (9%).

Those three facts are the real story, and they're all fixable.

The vendor's own docs say one layer isn't enough

You don't need to take a third party's word for this. OpenAI's own agent-building guide says a single guardrail is unlikely to provide enough protection, and that using multiple, specialized guardrails together creates more resilient agents (OpenAI practical guide).

Its Agent Builder safety documentation is similarly blunt: the guardrails nodes alone are not foolproof, and are described as an effective first wave of protection. They can redact PII and detect jailbreak attempts (OpenAI safety docs). The AgentKit announcement describes Guardrails as an open-source, modular safety layer that can mask or flag PII and detect jailbreaks, deployable standalone or through Python and JavaScript libraries (AgentKit announcement).

The docs also flag a specific MCP risk: a model may send more data to an MCP server than the user expected, and guardrails don't give you full control over what the model shares with connected MCPs (OpenAI safety docs).

The takeaway: the vendor treats its guardrails as layer one. If your security program is "we turned on layer one," the vendor's own documentation says you're not done.

A layered stack you can build without a security team

Here is the structure I use when hardening a production agent. Each layer fails independently, which is the point.

Layer 1 is the only one most teams have. Layers 2 through 6 are where the failures that matter get caught. The sections below take them in order.

Layer 2: Guard the tool call, not just the prompt

Prompt-level filtering catches what the model reads and says. The damage from an agent happens when it acts. In the OpenAI Agents SDK, tool guardrails run on every guarded function-tool invocation, including local MCP tools when their server configures guardrails; input guardrails run before execution and output guardrails run after (Agents SDK docs).

Whether or not you use that SDK, the pattern is portable: validate arguments before the tool runs, validate results before they go back to the model. Here's a vendor-neutral sketch:

from dataclasses import dataclass

@dataclass
class ToolPolicy:
    allowed_tools: set[str]
    max_recipients: int = 1
    blocked_domains: tuple[str, ...] = ()

POLICY = ToolPolicy(
    allowed_tools={"crm.lookup", "email.draft"},
    max_recipients=1,
    blocked_domains=("pastebin.com", "transfer.sh"),
)

def check_tool_call(name: str, args: dict) -> tuple[bool, str]:
    if name not in POLICY.allowed_tools:
        return False, f"tool '{name}' not on allowlist"
    if name == "email.draft":
        recipients = args.get("to", [])
        if len(recipients) > POLICY.max_recipients:
            return False, "too many recipients"
    for v in args.values():
        if isinstance(v, str) and any(d in v for d in POLICY.blocked_domains):
            return False, "blocked destination in arguments"
    return True, "ok"

def run_tool(name, args, tool_fn):
    ok, reason = check_tool_call(name, args)
    if not ok:
        log_denied(name, args, reason)   # your logger
        return {"error": f"denied: {reason}"}
    result = tool_fn(**args)
    return scrub_output(result)          # strip secrets/PII before the model sees it

Notice that this is plain code, not a model call. A deterministic check can't be talked out of its decision by a clever prompt, which is exactly why it belongs alongside the probabilistic guardrails.

Layer 3: Human approval where it counts

OpenAI's documentation tells developers to always enable tool approvals when using MCP tools, so end users can review and confirm every operation, including reads and writes. In Agent Builder, this is done with the human approval node (OpenAI safety docs).

Approving every action defeats the purpose of automating. A workable middle path is a tiered policy:

# approval-policy.yaml
tiers:
  auto:        # no approval needed
    - crm.lookup
    - calendar.read
  confirm:     # one-click human approval
    - email.send
    - crm.update
    - invoice.draft
  deny_by_default:   # needs explicit, logged override
    - payments.*
    - files.delete
    - admin.*

Start strict, then promote tools to auto only after you've watched them behave for a few weeks. It's much easier to relax a gate you can see than to discover a missing one after an incident.

Layer 4: Fix credential sharing first

If you do one thing from this post, do this. Among organizations with agents in production, 62% let their agents share credentials (VentureBeat). An earlier VentureBeat wave (June 2026, 107 enterprises) found 69% of enterprises run agents with credential sharing somewhere in their deployments, with incident rates of 49% for companies with 101 to 1,000 employees and 63% for companies with more than 1,000 (VentureBeat). Those waves had different samples, so don't treat the numbers as a trend line. The practice is the point.

Why it matters: one shared key means one compromised agent equals access for all of them, and your logs can't tell you which agent did what.

Concrete rules:

• One identity per agent. Each agent gets its own API key or service account.
• Least privilege per identity. The invoice agent doesn't need CRM write access.
• Short-lived tokens where the target system supports them.
• No wildcard scopes. The MCP security best-practices guidance specifically recommends avoiding scopes like *, all or full-access (MCP security best practices).

A minimal setup:

# One secret per agent, injected at runtime, never baked into images
export AGENT_INVOICE_KEY="$(vault kv get -field=key secret/agents/invoice)"
export AGENT_TRIAGE_KEY="$(vault kv get -field=key secret/agents/email-triage)"

# Verify no two agents share a credential (simple audit)
sha256sum <(echo "$AGENT_INVOICE_KEY") <(echo "$AGENT_TRIAGE_KEY") \
  | awk '{print $1}' | sort | uniq -d
# any output = a duplicate = fix it

You don't need Vault specifically; a secrets manager from your cloud provider does the same job. The requirement is separation and rotation.

Layer 5: Isolate the risky agents

Only 9% of respondents said isolating high-risk agents best describes their security program (VentureBeat). For a small team, isolation can be simple:

• Separate the agents that read untrusted input (inbound email, web pages, uploaded files) from the agents that hold powerful credentials. An agent that reads arbitrary email and can also send payments is the classic bad combination.
• Sandbox local MCP servers. The MCP guidance recommends running local servers with minimal default privileges (MCP security best practices). In practice: a container with no network egress except what the tool needs, a read-only filesystem, and a non-root user.
• Don't treat a state handle as proof of identity. The same MCP guidance says servers must not treat possession of a state handle as authentication.

A basic container profile for a local MCP server:

docker run --rm \
  --read-only \
  --user 10001:10001 \
  --cap-drop ALL \
  --network mcp-restricted \
  --memory 512m \
  -v "$(pwd)/workdir:/work:ro" \
  my-mcp-server:latest

It won't stop every attack. It means a compromised tool server can't casually read your home directory or call out to arbitrary hosts.

Layer 6: Log, map to a risk list, and review

You can't respond to what you can't see. Log every tool call with: agent identity, tool name, arguments (with secrets scrubbed), result status, and whether a human approved it. Review denied calls weekly. A spike in denials is often the first visible sign of a prompt-injection attempt or a misconfigured prompt.

For a checklist to map your controls against, look at the OWASP Top 10 for Agentic Applications 2026 from the OWASP GenAI Security Project, which lists ten risk categories (ASI01 to ASI10) including Agent Goal Hijack, Tool Misuse and Identity & Privilege Abuse, and was built with input from more than 100 security experts, researchers and practitioners. It's voluntary and has no legal status by itself. I haven't confirmed its exact publication date or every category name against the official OWASP page, so check the primary source at genai.owasp.org before citing specifics in a compliance document.

A quick self-audit using the layers above:

1. Does each agent have its own credential? (Layer 4)
2. Is every tool on an allowlist with validated arguments? (Layer 2)
3. Are irreversible actions gated by a human? (Layer 3)
4. Are untrusted-input agents separated from privileged agents? (Layer 5)
5. Could you answer "which agent did this, and who approved it?" from your logs? (Layer 6)

If you answer "no" to two or more, you have more to fix than any single vendor's guardrails will cover.

How BizFlowAI approaches this

I'm a senior engineer who builds AI automations for small teams. When I build agents, the guardrails the model vendor ships are layer one, and I treat them that way: useful for PII redaction and jailbreak detection, never the whole program. The rest of the stack is the unglamorous part: per-agent credentials, allowlisted and validated tool calls, human approval on anything irreversible, sandboxed MCP servers, and logs someone actually reads. That's the same layered pattern the vendor documentation itself recommends.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.