Add failOpen to CES Guardrail llmPromptSecurity

[sirohia]

Add failOpen field to llmPromptSecurity in google_ces_guardrail and google_ces_app_version

This PR adds the missing fail_open attribute to the llm_prompt_security block in the google_ces_guardrail and google_ces_app_version resources, achieving full API parity for this security feature.

Documentation

• API Reference: Guardrail.LlmPromptSecurity
• Terraform Resource: google_ces_guardrail

Rationale

The failOpen field at the root of the llmPromptSecurity object was missing from the Terraform provider schemas. This field determines whether the guardrail fails open (allowing user queries to pass through if LLM classification fails) or closed. Without it, users were unable to configure this critical fallback behavior when using the default system security settings.

Technical Details

• Guardrail Schema Modification: Added failOpen (Boolean) to llmPromptSecurity properties in Guardrail.yaml.
• AppVersion Schema Modification (API Parity): Added failOpen (Boolean, read-only output: true) under the nested guardrails.llmPromptSecurity properties in AppVersion.yaml to ensure complete schema parity across resources.
• New Example: Created the template ces_guardrail_llm_prompt_security_fail_open.tf.tmpl to demonstrate usage with default_settings and fail_open = true.
• Acceptance Test: Added TestAccCESGuardrail_cesGuardrailLlmPromptSecurityFailOpenExample_update to ces_guardrail_test.go.
  • Design Note: The test uses an inverted lifecycle flow (Create without block -> Update to add block with fail_open = true) to robustly handle proto3 default-value (false) omission in API responses, avoiding Terraform "empty nested block" diff loops.

Verification Results

• Successfully generated the google and google-beta providers using PRODUCT=ces.
• Acceptance tests ran and passed successfully on the generated provider (TestAccCESGuardrail_cesGuardrailLlmPromptSecurityFailOpenExample_update).

ces: added `fail_open` field to `llm_prompt_security` block in `google_ces_guardrail` resource

ces: added read-only `fail_open` field to `llm_prompt_security` block in `google_ces_app_version` resource

[github-actions]

Googlers: For automatic test runs see go/terraform-auto-test-runs.

@roaks3, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look.

You can help make sure that review is quick by doing a self-review and by running impacted tests locally.

[sirohia]

@DanKotowski fyi. thanks

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes for commit b0c46c3:

Diff report

Your PR generated the following diffs in downstream repositories:

Repository	Diff Link	Changes
google provider	View Diff	8 files changed, 281 insertions(+)
google-beta provider	View Diff	8 files changed, 281 insertions(+)
terraform-google-conversion	View Diff	1 file changed, 11 insertions(+)
Open in Cloud Shell	View Diff	4 files changed, 134 insertions(+)

Test report

Analytics

Total Tests	Passed	Skipped	Affected
66	64	0	2

Affected Service Packages

• ces

Learn how VCR tests work

---

Step 1: Replaying Mode

Action taken

Found 2 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit.

Click here to see the affected tests

• TestAccCESGuardrail_cesGuardrailLlmPromptSecurityFailOpenExample
• TestAccCESGuardrail_cesGuardrailLlmPromptSecurityFailOpenExample_update

View the replaying VCR build log

---

Step 2: Recording Mode

Recording Mode	Replaying Rerun	Test Name
✅ Log	✅	TestAccCESGuardrail_cesGuardrailLlmPromptSecurityFailOpenExample
✅ Log	✅	TestAccCESGuardrail_cesGuardrailLlmPromptSecurityFailOpenExample_update

🟢 All tests passed!

View the recording VCR build log or the debug logs folder for detailed results.

@sirohia, @roaks3 VCR tests complete for b0c46c3!

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes for commit 734e91c:

Diff report

Your PR generated the following diffs in downstream repositories:

Repository	Diff Link	Changes
google provider	View Diff	8 files changed, 281 insertions(+)
google-beta provider	View Diff	8 files changed, 281 insertions(+)
terraform-google-conversion	View Diff	1 file changed, 11 insertions(+)
Open in Cloud Shell	View Diff	4 files changed, 134 insertions(+)

Test report

Analytics

Total Tests	Passed	Skipped	Affected
66	66	0	0

Affected Service Packages

• ces

Learn how VCR tests work

---

Step 1: Replaying Mode

🟢 All tests passed in Replaying mode! No Recording was needed.

View the replaying VCR build log

@sirohia, @roaks3 VCR tests complete for 734e91c!

[roaks3]

LGTM, but wondering if the tests/docs are appropriate

[roaks3]

Just checking, is this worth of its own entire test and example in the docs? I can't tell if this is a major use case, or a simple toggle of which there are many.

[sirohia]

I added this as a separate example because of the API level constraint and to document a distinct configuration path. llm_prompt_security block has two mutually exclusive configuration paths in the backend Root level fail_open and custom_policy.fail_open. If custom_policy is configured, the backend API ignores the root-level fail_open completely and does not return it in GET responses.
The existing example (ces_guardrail_generative_answer_llm_prompt_security) focuses on the custom_policy setup where users configure their own Gemini models and prompts. The new example demonstrates default root level fail_open settings which as added as part of the PR.

@roaks3 please let me know if this looks good or you have additional feedback.

[roaks3]

Similar to my other question: could this be simply added to an existing test, or is it representing an isolated use case where we want to test updating the field on its own.

[sirohia]

This is kept as separate test case to verify the root-level fail_open lifecycle without causing state issues or diff loops.
If we tried to merge this into existing GenerativeAnswerLlmPromptSecurity test (which uses custom_policy), the API would ignore the root-level fail_open and omit it from the response.
Also, Optional booleans in proto3 APIs are omitted from the response when set to false (default value). To test this robustly, the test uses an inverted lifecycle flow (Create without the block -> Update to add the block with fail_open = true). This lets us verify both false (by baseline omission) and true (by explicit update) without hitting diff loops.

@roaks3 hope this is fine.

[roaks3]

LGTM, thanks for the responses