ABAC vs. RBAC for agents: choose the facts your policy needs

Suppose a deployment agent has the release-operator role. It can deploy the Payments team's service to staging. Now it asks to deploy another team's service to production. Should the same permission cover both requests?

Start with that question before choosing role-based access control (RBAC) or attribute-based access control (ABAC). You need to know who owns the service, which environment is involved, and who approved the production release. Then decide how your system will check those facts.

Which facts should change the answer?

For this hypothetical deployment workflow, assume operators may deploy their own team's services to staging, while production requires additional authority.

Fill this in with the deployment owner. Dome doesn't automatically supply every fact in the table. The deployment service may need to check ownership and release approval itself.

The authorization foundation explains the decision layers. This worksheet chooses the inputs required within those layers.

Try roles and attributes against the same requests

NIST's ABAC definition describes decisions based on subject, object, operation, and potentially environmental attributes. A role can be one input in such a design.

NIST's RBAC discussion also allows constraints and additional access-time checks. It is inaccurate to give RBAC only a static username while giving ABAC every trustworthy enterprise fact.

One implementation might use roles for each service and environment. Another might combine a smaller role set with resource relationships. Both can retain the same transaction-specific approval in the backend. Evaluate them against the worksheet, not against a label.

Who keeps the permissions up to date?

For the role-heavy design, estimate the assignments and reviews caused by adding a service, moving a team, or introducing an environment. If each change creates many combinations, inspect how reviewers will recognize an unintended grant.

For an attribute-based design, find out where each value comes from and who can change it. Who may change a resource label? When does a departed employee's group membership stop affecting live decisions? What happens when a required value is absent?

An ownership attribute is useful only if you can trust it. A short rule that reads an outdated team label can be harder to maintain than a longer, explicit set of roles.

Use the same cases for both candidates: expected staging deployment, wrong-team target, production without approval, missing represented user, and missing resource classification. Then ask a second reviewer to explain each decision from the proposed configuration.

Keep administration separate from runtime authority

Dome's permissions model separates platform RBAC from runtime rules. A person's permission to configure an agent does not automatically authorize that agent to call a tool. An agent's runtime permit does not grant its operator platform administration.

At runtime, Dome's authorization model evaluates supported agent, action, resource, and context information. The worksheet identifies which distinctions can be expressed there and which require an authoritative downstream check.

This separation also helps the review: assess who can change the policy independently from what the policy permits.

Choose the design a reviewer can explain

If stable roles and existing backend checks express the intended boundary cleanly, keep them. Add attributes where a real required distinction justifies their sourcing and maintenance.

Complete the worksheet for one consequential operation before adding policy machinery. For each fact, name its owner and decide what happens when it is missing. Choose the model that makes those checks easiest to maintain.