Review AI workload creation as indirect credential authority

Ask what the helper can cause, not only what it can read

A fictional operations assistant prepares a preprocessing worker for public teaching notes. Its operator says the helper cannot read Secrets directly, so creating a Pod must be harmless. That argument examines the helper’s own read operation while leaving the resulting workload’s inputs and identity unresolved.

Select one ordinary Pod proposal W-A in namespace N-A, with a trusted fixed worker and non-confidential input. No controller, privileged workload, host access, arbitrary model-generated specification or cluster change is proposed. The purpose is to review the authority graph before any execution decision.

Every sheet and eight cards are PROPOSED_UNRUN. No Pod, ServiceAccount, Secret, token, manifest, API request, cluster, permission probe, runtime fixture or model operation was created or inspected. The labels name no real resources or credentials.

Recognize the documented indirect edge

The Kubernetes RBAC good-practices guide explains that workload creation in a namespace implicitly accesses resources such as Secrets that can be mounted in Pods. Because Pods can run as any ServiceAccount there, that permission also implies those accounts’ API access levels. It describes boundaries within a namespace as weak.

This differs from the role-editing and binding worksheet, whose positive excludes workload creation. Here the concern is a transitive capability after a creation grant already exists. A review limited to the helper’s direct resource-read list can omit the consequential workload path.

That documentation is a reason to investigate actual exposure, not evidence that a particular helper has obtained anything. Existing admission restrictions and the complete effective authority still need independent evidence. Do not claim either compromise or successful prevention from a role’s name.

Keep the initiating helper and worker identity separate

Our proposed receipt names helper H-A, worker plan W-A and selected ServiceAccount S-A separately. H-A’s business purpose does not make every capability reachable through S-A necessary. Nor does an approved image settle which data the proposed workload may consume.

Write the intended task first: produce one bounded draft from admitted public notes, with no cluster API access needed. Then require the complete proposal to match that need. The application must independently establish how substitutions of identity, inputs or executable are prevented. A model’s instruction to use the right account supplies none of that enforcement.

The ServiceAccount task guide identifies the Pod’s selected account through spec.serviceAccountName; API access depends on the authorization policy. Record the selected association and complete current permissions rather than borrowing the helper’s identity or treating an account name as a stable privilege certificate.

Treat automatic token mounting as one control

The same task guide documents opting out of automatic API-credential mounting with automountServiceAccountToken: false. When both the ServiceAccount and Pod specify a value, the Pod specification takes precedence.

For W-A, the proposed no-API task requires an effective opt-out and rejects proposal changes that undo it. Checking only S-A’s setting leaves the Pod-side decision unreviewed. The requirement concerns this selected input plan, not a statement about every token mechanism.

Keep explicit protected inputs as a separate gate. A token opt-out does not answer whether the complete workload proposal includes a Secret, an unrelated credential source or unapproved application data. This worksheet provides neither a token-revocation method nor proof of confidential-data absence, isolation, erasure or no network access.

Use one original capability receipt

The useful positive is conditional eligibility of that restricted preprocessing proposal. Actual authentication, cluster behavior, template integrity, supported admission enforcement, complete inputs, account authority, runtime restrictions and current application rights are unimplemented and unknown. Any missing required premise blocks real admission.

If H-A can instead submit arbitrary specifications outside the reviewed path, the receipt cannot honestly establish the fixed-plan boundary. Do not replace the enforcement question with a screenshot of the intended template or an assurance that the model usually follows it.

Walk eight inert workload decisions

Keep the conclusion smaller than cluster safety

This is no complete cluster-hardening, namespace-isolation, escalation-prevention or arbitrary-workload sandbox design. It implements no admission mechanism or effective-permission collector. Network-policy eligibility and configuration rollout evidence remain separate from the credential-authority graph.

The two maintained pages showed v1.37 navigation; their displayed modification dates were 18 August 2026 and 31 October 2024 respectively. No installed cluster, authorization plugin or present settings were observed.

Boundary remains prelaunch with planned request-path checks, not a shipped Kubernetes workload or credential manager. Its local mock-policy evidence concerns different behavior and validates none of these proposed cards.