Cloud and local BYOK

BYOK separates customer model spend from Dharma analysis and orchestration while keeping the same organization, trajectory, evaluation, and remediation records.

GCP Vertex BYOK

Dharma uses Workload Identity Federation to invoke an explicitly configured customer runtime. No service-account JSON key is created, downloaded, or stored by Dharma.

1. Select GCP Vertex BYOK in the organization onboarding flow.
2. Enter the project, project number, region, runtime service, runtime HTTPS URL, service account identity, and spend ceiling.
3. Apply the portal-generated workload-identity bindings in the customer project.
4. Run verification from Portal -> Agent Fabric -> Cloud BYOK.
5. Activate only after identity, trace, usage, and tenant-isolation checks pass.

The API contract is GET/POST /api/v1/orgs/{orgId}/agent-fabric/byok/gcp. The configured runtime URL and cloud identity remain server-side and are not returned to public browser code.

Local BYOK

Local provider credentials remain on the enrolled device. The outbound relay carries signed tasks and bounded evidence capsules, not provider secrets. Local execution does not create a Dharma provider-token charge; semantic analysis, storage, and orchestration may create Dharma usage events.

What remains common

Managed ADK, GCP BYOK, and local endpoints can attach to the same logical repository agent. Organization-scoped evaluations may select logical agents or exact endpoints across those execution modes. Remediation can then produce independently reversible child bundles for each affected agent.

Rotation and removal

For GCP, rotate or remove the workload-identity binding and re-run verification. For local providers, revoke the Dharma device and rotate the provider credential locally. Offboarding must prevent new execution before deleting retained evidence under the organization policy.