Your workforce uses generative AI (GenAI) tools with or without your approval. Use network-level GenAI governance to see that use and act on it, without blocking it.

Network-level GenAI governance inspects traffic bound for GenAI services. It applies policy to each request before that request reaches its destination. F5 Workforce AI Security governs public GenAI services, such as ChatGPT and Microsoft Copilot. It also governs private models your company runs in its own cloud.

It is neither a block list nor a secure access service edge (SASE). If you block a public GenAI service outright, you lose insight into how your workforce uses it. A SASE policy can allow or block a whole GenAI domain by URL category. It can't read the prompt inside a request.

Workforce AI Security reads that content. It then applies policy to the single request, not the whole domain. It runs alongside your SASE stack rather than replacing it.

This document covers three things:

For setup steps, see Initial configuration steps.

Traffic steering sends only GenAI domains to Workforce AI Security. Other web traffic follows its typical path. Workforce AI Security supports three steering methods:

Workforce AI Security must identify the user behind a request. Without an identified user, it can't apply a Group Policy or record the request against a person. It either receives an identifier with the request, or it prompts the user to log in.

Most SASE vendors' forward-to-proxy policies support adding an X-Authenticated-User header to a forwarded request. Workforce AI Security accepts that header. When all three of these hold, the platform authenticates the request without a prompt:

A proxy PAC deployment sets authentication on the Proxy connector instead. Your choice of setting changes what User Activity records:

Every tenant has one Default Policy, and it covers all users. Group Policies are additive. Each one grants a named group more access than the Default Policy allows, and never less.

Directory Sync imports users and groups from your directory service. It uses the System for Cross-domain Identity Management (SCIM) protocol. You then assign a Group Policy to a group rather than tracking each person by hand.

Inside a policy, the Public Service Catalog sets which GenAI services a user can reach.

Content Controls check a request for High-risk Request, Confidential Data, Programming Language, Harmful Content, and Prompt Injection.

PII Detection checks for personally identifiable information (PII) separately, entity by entity. Its entities cover data such as Phone Number, Credit Card, Email Address, and IP Address.

Each control carries its own action: Monitor, Warn, Tag, Mask, Delete, Synthesize, or Block.

You run a new tenant and you don't yet know how your workforce uses GenAI. A new tenant monitors GenAI traffic and logs violations by default. That changes nothing about what a user can do. You review User Activity for single sessions. You review Insights for adoption and risk trends. When the data supports a decision, you move a control from Monitor to an action that changes the request.

You need to stop confidential data and PII from reaching a public GenAI service. Content Controls and PII Detection read the request before it leaves your environment. Each control has its own action. You can mask or delete one value and let the rest of the request continue. You don't have to block the user.

Your engineering team needs GenAI services that the rest of the company must not reach. Directory Sync imports the Engineering group from your directory service. You assign a Group Policy to that group. That policy adds those services on top of the Default Policy. Everyone else stays on the Default Policy alone.

Network-level GenAI governance adds controls that a SASE platform doesn't provide on its own.

For more information, see: