kagent SandboxAgent has a native domain allowlist as well as role and tool bindings. MCP server credentials and resource-level rules still need their own native policies. Keep each permission in the existing format that actually enforces it.
Native access layers, without a new DSL
The current kagent SandboxAgent API offers spec.sandbox.network.allowedDomains with default-deny outbound access for sandboxed execution, in addition to the declarative role, model and MCP tool bindings. This is a concrete existing format that gets closer to one file per agent. It does not turn a list of tool names into authorization over arbitrary tool arguments or backing resources. The MCP server's own credentials, server-side authorization, Kubernetes ServiceAccount/RBAC and workload/network policy determine those boundaries. Sources: https://kagent.dev/docs/kagent/0.x/resources/api-ref/ ; https://kagent.dev/docs/kagent/0.x/concepts/agents/ ; https://kubernetes.io/docs/concepts/security/rbac-good-practices/
The ready-made OpenShell policy YAML can describe additional network, filesystem, process and MCP-name controls, but is a separate sandbox policy, not a kagent field to invent or assume integrated. It supports local MicroVM and Kubernetes runtimes, which is another evaluation path if a single policy language across environments becomes a priority. Its MCP rule does not inspect tool arguments. Sources: https://docs.nvidia.com/openshell/latest/how-it-works/policies/schema ; https://docs.nvidia.com/openshell/latest/about/support-matrix
The first practical test should use unchanged, version-pinned upstream examples: apply one kagent agent on the actual k3s version, invoke it through A2A from a narrow communication adapter, verify a permitted MCP tool call and a denied one, then repeat in local development. kagent's documented local CLI flow targets a Python ADK project and Docker Compose rather than executing the declarative CRD directly, so microsandbox parity must not be assumed: https://kagent.dev/docs/kagent/0.x/getting-started/local-development/
kagent 0.x to 1.x is a schema and deployment migration, not a routine in-place upgrade: https://kagent.dev/docs/kagent/1.x/operations/upgrade-from-0x/ . This is a selection risk to weigh against Goose Recipe plus a separate runtime.