A Read-Only Account Mints and Destroys Data-Pipeline Credentials

The Vulnerability

The platform offers a self-hosted data-pipeline agent: software a customer installs on their own infrastructure so the platform can move data without reaching directly into the customer's source systems. This is the install path sold to regulated customers who cannot let an external vendor touch their data sources. These agents are managed from the account dashboard, and creating or deleting one provisions or tears down a live data-plane identity.

The platform ships a documented role hierarchy enforced by a role-based access control model. The lowest role, the read-only reviewer, is documented as view-only across the account, destinations, connections, and transformations, with no ability to create, edit, or delete anything. It is the role customers assign to auditors, contractors, support staff, and other read-only observers.

The flaw is that agent management is not governed by the access control model at all. There is no permission row, for any role, that grants the ability to create or delete these agents. Because nothing checks it, every role, including the read-only reviewer, can do it. The endpoints that provision and destroy agents authorize on session validity and account membership alone, never on role:

• POST /api/internal/accounts/{id}/proxy-agent (create a proxy agent)
• POST /api/internal/accounts/{id}/deployment-agent (create a deployment agent)
• DELETE /api/internal/accounts/{id}/proxy-agent/{agentId}
• DELETE /api/internal/accounts/{id}/deployment-agent/{agentId}

The gap also surfaces in the user interface. On the deployment agents settings page, the read-only reviewer is shown a fully working "Add agent" wizard and a per-row "Delete" button. The proxy agents page hides those controls in its interface, but the underlying endpoints still accept the reviewer's requests, so the proxy half is exploitable directly through the API.

The Attack

The scenario is the everyday one: an account owner invites a third party (an auditor, contractor, or support person) and assigns them the documented read-only reviewer role. That user is the attacker. No administrator action beyond the initial invite is required, and the attacker acts entirely from their own session.

Destroying the Admin's Agents

From the read-only reviewer session, the deployment agents settings page renders a working Delete control on rows the administrator created. Selecting the admin-owned agent and confirming the delete destroys it. Any connector routing through that agent stops syncing until an administrator re-installs the agent on their own infrastructure. The same delete works against proxy agents through the API:

DELETE /api/internal/accounts/{id}/proxy-agent/{agentId}
-> 204 No Content   (admin-owned agent removed)

Minting New Agents

Creating agents is a single request to each endpoint. From the reviewer's authenticated browser session, a short console snippet reads the session's account identifier and anti-forgery token, then posts to the create endpoints:

POST /api/internal/accounts/{id}/proxy-agent
  { "displayName": "agent_proxy", "deploymentType": "docker" }
-> 200 OK   { "agent_id": "..." }

POST /api/internal/accounts/{id}/deployment-agent
  { "displayName": "agent_deploy", "deploymentType": "DOCKER" }
-> 200 OK   { "agent_id": "..." }

Both return success for the read-only role. The newly created agents appear in the dashboard with the reviewer listed as their creator, a role with zero documented write permissions provisioning data-plane infrastructure.

The Proxy Credential Is Live

The proxy agent the reviewer mints is not a placeholder. Its provisioning response carries an authentication token that exchanges, at the platform's configuration endpoint, for a mutual-TLS certificate to the platform's orchestrator. Driving the live orchestrator with that reviewer-minted certificate confirmed it is a working data-plane credential: a token-regeneration call returned success. The credential's identity is bound to the certificate it was issued with, so attempts to impersonate another agent by spoofing identity headers failed closed, and no cross-agent or cross-account data read was possible. The reviewer mints a real, live identity on the data plane, scoped to its own account.

The Impact

A documented read-only role can, from its own session with no administrator interaction:

• Delete the administrator's deployment and proxy agents, halting every data pipeline routed through them until an administrator re-installs the agent on their infrastructure.
• Create new proxy and deployment agents the role has no permission to create.
• Mint a live data-plane credential (a working mutual-TLS identity to the platform's orchestrator) through the proxy agent it created.

The blast radius is bounded to the account the reviewer belongs to. A reviewer session aimed at any other account is rejected, so this is not a cross-tenant break. Within the account, however, the impact is destruction of the entire data-plane fleet plus creation of rogue agents, performed by the role companies hand to outsiders precisely because it is supposed to be harmless. That account-scoping is why this is High rather than Critical.

Remediation

• Add agent management to the access control model as explicit permissions, and gate the create and delete endpoints on those permissions server-side, not only in the user interface.
• Deny agent create and delete to the read-only reviewer role and any other role not explicitly granted the new permission.
• Hide the "Add agent" and "Delete" controls from roles that lack the permission, so the interface matches the enforced policy on both the deployment and proxy settings pages.
• Restrict deletion of an agent to the user who created it or to administrators, rather than any account member.
• Audit existing agents for any provisioned by non-privileged roles, and rotate or revoke any credentials minted outside the intended permission set.

Responsible Testing

All testing was performed on accounts the researcher owns and administers, using a read-only reviewer invited into one of them. Every proxy agent and deployment agent created during testing was deleted afterward. No third-party account or production data was touched.