Create the concept of Guardrail agents

Additional information from weekly meeting:

The UI/UX has to make it simple to create and manage guardrails. However, since there are many things to configure, this could become complex.

Guardrails can be general and apply to general functionality such as AI Translation or Content Suggestions, where you might just need to block things like PII data or flag things like <script> tags.

Guardrails can also be very specific and be tied to a single agent or a tool.

A specific example of a guardrail for a single agent might be something like:
“Check that the text in the image only includes cooking instructions—nothing else.”
You’d only want that guardrail running for the agent that generates food recipes—not every AI process.

A UI/UX should work for all use cases.

"it can immediately raise an error, which stops the expensive model from running and saves you time/money."

From the OpenAI Agents SDK, I can't see if Guardrails HAVE to stop the execution or CAN cut the operation. I think it should be the "default" approach for guardrails but not the only. Instead it should be possible (even if not possible with version 1.1 to)

• Have guardrails stop the execution.
• Have guardrails go back to the agent to give them another go at it.
• Have guardrails trigger some kind of end-user action that would allow the execution to continue where its left off. Terminate it, or start down a new path.

I don't think we should build all the above options above. But I think we should think about it as a possibility.

lussoluca → changed the visibility of the branch 3518963-meta-create-the to hidden.

lussoluca → changed the visibility of the branch 3518963-meta-create-the to active.

lussoluca → changed the visibility of the branch 3518963-meta-create-the to hidden.

Sorry, I wanted to push an initial stub, but then I realized that this issue was opened into ai_agents module (I worked on the ai module...)

I think that guardrails are a generic concept that can be applied to every interaction with an LLM, not only when using agents. Maybe we should move this issue to the ai project?

You are right Luca - we will need an issue here as well, for actual UI implementation, but that is dependent on the other issue. Will move.

lussoluca → changed the visibility of the branch 3518963-meta-create-the to active.

lussoluca → changed the visibility of the branch 3518963-meta-create-the to hidden.

Since guardrails can appear in many places such as automators, agents, tools, content suggestions, CKEditor, etc. we need a list of configuration UIs where the functionality can be added. Best would be with screenshots as we might need UX work to create a pleasant configuration experience.

Switching to the correct tag

Add skill tags for issue discovery

Since guardrails can appear in many places such as automators, agents, tools, content suggestions, CKEditor, etc. we need a list of configuration UIs where the functionality can be added. Best would be with screenshots as we might need UX work to create a pleasant configuration experience.

I agree with you, maybe we should open a separate issue for the UI part?

A new Plugin type named AiGuardrail is added to define guardrails implementation. A guardrail plugin should implement ConfigurableInterface and PluginFormInterface from Core (to make the plugin configurable by a form). A new interface is created to mark plugins that need access to the AiPluginManager service: NeedsAiPluginManagerInterface.
An

AiGuardrail

plugin must implement the processInput method that takes a ChatInput as input and returns a GuardrailResultInterface. The AI module provides some implementation for the

GuardrailResultInterface

:

• PassResult: indicates the input can pass without changes
• StopResult: indicates the input should not be processed further (and a standard message has to be sent to the user)
• RewriteInputResult: indicates the input should be rewritten (maybe to remove some PII)
• RewriteOutputResult: indicates the output should be rewritten (maybe to remove unwanted information from a LLM response)

A new configuration entity named ai_guardrail is added, including an ID, label, description, the AiGuardrail plugin to use, and the plugin settings.
An AiGuardrailForm class is provided to render an AiGuardrail plugin form and to save the results as an AiGuardrail entity.
A single guardrail is usually insufficient to protect a conversation between users and an LLM. We want some guardrails to run on the chat input and some others to run on the LLM response, before sending the text to the user. To represent this standard behaviour, a new ai_guardrail_set configuration entity is added, including an ID, label, description, a list of guardrails plugins that must be run before sending the prompt to an LLM (pre_generate_guardrails), and a list of guardrails plugins that must be run after a response from an LLM is received (post_generate_guardrails). An AiGuardrailSetForm class is provided to create and configure a guardrail set with a UI.
Guardrails checks run in an event subscriber, configured to listen to ai.pre_generate_response and ai.post_generate_response events.
An initial integration with the AI module is provided in the chat_generator AiApiExplorer plugin: a new select is added to the Advanced accordion that can be used to choose which ai_guardrail_set to use.

See the attached screen recording for a demo of the UI.

First POC is ready to be reviewed.

• This MR adds the guardrail and guardrail_set concepts
• This MR adds guardrail support for agents
• This project → implements an initial set of guardrails (I've separated the code for guardrails to ease dependency management)