F5 Workforce AI Security: Agent Action Controls and MCP Governance

Quick answer

F5 announced Workforce AI Security on September 9, 2026, extending its AI Security Platform with controls for how employees use AI and, more importantly, what AI agents can do on employees' behalf.

The product is designed to discover public and private AI usage from network traffic, classify user intent, inspect prompts and sensitive data, maintain audit-ready logs, and apply policy to agent tool calls across MCP servers and supported agent tools before an action executes.

That last capability is the real story. Enterprise AI governance is moving beyond deciding which chatbot employees are allowed to open. As coding agents, browser agents and workflow agents gain tools, credentials and access to business systems, companies need a policy layer around execution, not only around prompts and model access.

TowCue's view: this is the same architectural shift now appearing across agent products. The useful security boundary is increasingly outside the model — in identity, network policy, tool permissions, approvals and logs that can constrain an agent even when its reasoning is wrong.

What F5 announced

F5 describes Workforce AI Security as an agentless layer for enterprise visibility and control. The September 9 announcement positions it as a way to govern both employee AI use and actions taken by AI agents on users' behalf.

The official product page lists six core capabilities:

AI discovery across services visible in enterprise traffic
a centralized inventory of AI services, models and agent tools
usage insights covering prompts and data flows
adaptive controls that can route users toward approved models or block risky services
audit-ready logging of AI interactions and policy decisions
agent action controls that inspect and classify tool calls across MCP servers and supported agent tools before execution

For security teams, the distinction between the first five and the sixth matters. Discovering an unsanctioned chatbot is a visibility problem. Preventing an agent from making a dangerous tool call is an authorization and execution problem.

Why MCP and tool calls change the governance problem

Traditional enterprise AI controls were mostly built around questions such as:

Which AI websites are employees using?
Are users pasting confidential data into public models?
Which models are approved?
Can prompts containing PII be blocked or redacted?

Those questions still matter. But tool-using agents introduce a new path for risk.

An agent can potentially read files, query internal systems, modify tickets, create code changes, send messages or invoke APIs. With MCP becoming a common way to expose tools and context to AI clients, the control point is no longer only the prompt entering the model. It is also the tool request leaving the agent.

F5 says its platform can continuously discover and trace agent tool calls and MCP connections, then apply policy before supported actions execute.

That suggests an enterprise control model closer to API security than traditional chatbot filtering:

identify the user and agent
understand which tool is being requested
classify the business intent and data involved
evaluate policy
allow, redirect, redact or block the interaction
record what happened for later investigation

The important idea is simple: an agent should not inherit unlimited authority just because the employee who launched it has broad access.

Agentless visibility is useful, but it has boundaries

F5 says Workforce AI Security can discover AI usage by passively analyzing mirrored network traffic, without installing another endpoint agent or browser extension. The company says this out-of-band analysis does not add latency to production traffic.

That can be attractive to large organizations because it reduces deployment friction and can reveal shadow AI that security teams did not know existed.

But passive visibility and inline enforcement are not the same thing.

TowCue would evaluate three boundaries carefully before relying on this architecture:

1. What traffic is actually visible?

Encrypted, local, private or non-network activity may require different integration points. Teams should verify what the product can observe in their own network architecture rather than assume every agent action is automatically covered.

2. Which tool ecosystems support pre-execution control?

F5's product page says it supports policy over MCP servers and supported agent tools. That wording matters. Enterprises should test the exact tools, clients and transports they use, especially for custom internal agents.

3. Is the policy passive or enforcing?

A dashboard that notices a risky action after the fact is valuable for forensics. It is not equivalent to a control that blocks the action before execution. Security reviews should distinguish discovery, logging and enforcement explicitly.

Prompt security is becoming execution security

F5's broader AI Security Platform already focuses on prompt injection, sensitive-data leakage, model risk and runtime guardrails. Workforce AI Security adds another dimension: the actions initiated through workforce AI.

That is important because the worst failure mode of a tool-using agent may not be an embarrassing answer. It may be a correct-looking action with the wrong scope.

Examples include:

a coding agent pushing a change to the wrong repository
an operations agent modifying a production setting instead of staging
a support agent exposing customer information through an external tool
a finance agent submitting a transaction beyond an intended limit
a browser agent following a malicious page instruction and invoking a connected tool

These failures are difficult to solve with prompt instructions alone.

A better architecture separates reasoning from authority:

The model proposes. Policy decides what it is allowed to execute.

The strongest use case may be mixed AI environments

Most enterprises will not standardize on a single AI vendor.

Employees already mix public chatbots, enterprise copilots, coding agents, automation platforms and custom internal agents. Models also change quickly, and the same agent may route among multiple models.

F5 is positioning its AI Security Platform as model-agnostic, with consistent policy across public and private models. If that works across the tools an organization actually uses, it addresses a real governance problem: security teams do not want to rebuild controls separately for every new model or AI application.

This also explains why network-level and identity-linked visibility is strategically interesting. The governance layer can remain relatively stable while models and agent interfaces change above it.

What this means for coding agents

Coding is one of the clearest environments where agent permissions are already expanding.

Modern coding agents can:

read an entire repository
run terminal commands
install packages
access MCP servers
open pull requests
call deployment or issue-tracking tools
use credentials exposed through local or enterprise environments

The natural temptation is to focus on the model: which coding agent is smartest, fastest or most autonomous?

For enterprise adoption, a second question is becoming just as important:

What can the agent reach, and who can prove that it stayed inside those boundaries?

A strong enterprise setup should make tool permissions, network access and credentials explicit rather than relying on the model to remember policy in its system prompt.

Who should care

Security and platform teams

Workforce AI Security is directly aimed at teams trying to inventory shadow AI, enforce model policies and add visibility around agent execution without deploying another endpoint client.

Companies adopting coding agents

If engineers are giving agents terminal, repository or MCP access, tool-call governance is becoming part of developer security — not a separate AI policy document.

Automation and operations teams

The more an AI workflow can update systems rather than merely summarize them, the more useful a pre-execution policy layer becomes.

CIOs evaluating multiple AI vendors

A model-agnostic control plane can be valuable when the organization expects its AI stack to change faster than its security architecture.

A practical control model for enterprise agents

TowCue would divide agent actions into four levels:

Level 1 — Read-only and reversible

Search, summarize, inspect logs, read documentation. These can usually run with broad autonomy and full logging.

Level 2 — Internal writes with low blast radius

Create drafts, update non-critical tickets or modify sandbox resources. Allow them under scoped identity and policy.

Level 3 — External or production-changing actions

Send customer communication, merge code, change production infrastructure or alter important records. Add deterministic policy checks and, where appropriate, approval.

Level 4 — Financial, destructive or credential-sensitive actions

Payments, deletions, secrets, account changes and high-impact production operations should have hard limits outside the model and strong human authorization.

The mistake is treating every action as either fully autonomous or fully manual. Good agent governance is about matching the control to the blast radius.

TowCue take

F5 Workforce AI Security is interesting because it reflects where enterprise AI is heading.

The first governance problem was shadow AI: employees opening unsanctioned chatbots and sending data to them.

The next governance problem is shadow agency: agents quietly receiving tools, credentials and system access, then taking actions through those connections.

Organizations will still need model policies and data-loss prevention. But those controls are no longer enough once AI can execute.

The durable enterprise architecture will probably look familiar to security teams:

identity + least privilege + network controls + policy enforcement + audit logs + approval for high-impact actions.

AI agents do not eliminate those principles. They make them more important.

The most trustworthy agent stack may not be the one with the most autonomous model. It may be the one where the model can be replaced tomorrow without changing the boundaries around what the agent is allowed to do.

F5 Workforce AI Security targets the next enterprise AI problem: controlling agent actions