fix(controller): decouple skills from privileged sandbox

[mesutoezdil]

Skills are loaded by the init container. The main container does not
need privileged=true for skill loading.

Before this change, any agent with skills got privileged=true on the
main container, which breaks restricted PSS clusters.

Now only BashTool sandbox (cfg.GetExecuteCode) sets privileged=true.

Fixes #1997

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the agent manifest generation and test fixtures so that configuring skills no longer implicitly makes the main container privileged; privileged mode is now reserved for explicit code-execution sandboxing.

Changes:

• Removed securityContext.privileged: true from golden manifest outputs for agents with skills/git-skills.
• Updated security-context tests to assert that skills do not set privileged security context on the main container.
• Simplified buildSkillsRuntime by removing the side-effect that forced code-execution isolation.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
go/core/internal/controller/translator/agent/testdata/outputs/agent_with_skills.json	Updates golden output to no longer include privileged main-container security context when skills are present.
go/core/internal/controller/translator/agent/testdata/outputs/agent_with_git_skills.json	Same golden output update for git-based skills.
go/core/internal/controller/translator/agent/security_context_test.go	Adjusts expectations: skills should not imply privileged main-container security context.
go/core/internal/controller/translator/agent/manifest_builder.go	Removes the “skills force code-exec isolation” coupling by dropping the needCodeExecIsolation mutation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jmhbh]

LGTM! makes sense to me

[EItanya]

The issue here is more nuanced. There are 2 features in our API, code execution and skills. Skills may execute code even if code_execution is not set. code_execution on the API specifically refers to executing code generated by the LLM, not code within skills themselves. We should probably deprecate the "code_execution" API feature altogether because it's very confusing

[mesutoezdil]

The issue here is more nuanced. There are 2 features in our API, code execution and skills. Skills may execute code even if code_execution is not set. code_execution on the API specifically refers to executing code generated by the LLM, not code within skills themselves. We should probably deprecate the "code_execution" API feature altogether because it's very confusing

skills run entirely in the init container, so whatever code they execute happens there, not in the main container. i try here only removes privileged from the main container, the init container is unaffected. is not correct?

[EItanya]

The issue here is more nuanced. There are 2 features in our API, code execution and skills. Skills may execute code even if code_execution is not set. code_execution on the API specifically refers to executing code generated by the LLM, not code within skills themselves. We should probably deprecate the "code_execution" API feature altogether because it's very confusing

skills run entirely in the init container, so whatever code they execute happens there, not in the main container. i try here only removes privileged from the main container, the init container is unaffected. is not correct?

No, skills are downloaded in the init container, but RUN in the main container