Permissions & IAM
Identity boundaries between Syntax and dUX, and what each system enforces.
Syntax and dUX are two distinct systems with two distinct identity boundaries. Understanding which side enforces what is the key to predicting behavior and to debugging permission errors when they happen.
The two identity boundaries
| Boundary | What it protects | Owned by |
|---|---|---|
| Syntax identity | Who you are within Syntax (user, role, org membership). | Syntax (Control Plane). |
| dUX identity | What infrastructure permissions Syntax has within your dUX organization. | dUX. |
A request from your harness to a managed-remote endpoint crosses both: it's authenticated as you in Syntax, then translated into a deployment-scoped operation that dUX accepts because Syntax has the right dUX-side permissions to drive it.
What Syntax enforces
- Authentication. The bearer token your harness sends to the Bridge.
- Authorization within Syntax. Whether you're allowed to deploy, scale, expose, or revoke under your role.
- Org policy. Whether the model you're trying to deploy is in the org's allowed catalog.
- Budgets. Whether the deployment fits your token / compute budget under the active policy.
- Audit. The audit log entry for the operation.
What dUX enforces
- Infrastructure permissions. Whether your Syntax org has the right to provision GPUs, set up ingress, etc. in your dUX organization.
- Resource quotas. Whether the requested deployment fits within your dUX-side quotas.
- Per-org isolation. Whether the deployment can be placed within your dedicated isolation boundary.
What this means in practice
- Permission errors from Syntax look like role / policy / budget failures. They have clear messages and tell you what to ask your org admin to change.
- Permission errors from dUX look like quota / capacity / IAM failures at the infrastructure layer. Syntax surfaces them with the dUX-side detail so the right team (your dUX admin or whoever owns the dUX org-level permissions) can resolve them.
Settings that matter
In Settings → Managed Remote, you can review:
- The dUX organization Syntax is currently configured to talk to.
- The effective dUX permissions Syntax has been granted.
- A simple quick-check that exercises the connection without deploying anything.
If any of those look wrong, work with your dUX administrator to adjust the permissions on their side.