Agent authorization

Agent authorization determines whether an identified agent may perform a requested operation on a resource under the applicable conditions. The decision may involve the agent's own authority, a represented user's entitlement, the requested arguments, and facts about the target resource.

NIST's ABAC definition provides a useful vocabulary: subject, object, operation, and relevant environmental attributes. For an agent's proposed action, those facts need to come from sources the service can trust.

Explore Dome: Authorization · Docs: Authorization model.

Turn a tool name into a business action

Suppose an agent can call a ticket-update tool. That tool might add a note, change an assignee, close a ticket, or alter its requester. A single permission named “update” can therefore cover several different effects.

Write the action as a sentence: “This agent, acting for this verified employee, may close this employee's open ticket.” That sentence reveals the facts the decision needs.

Action authorization checks whether the particular action, such as closing the ticket, is allowed. Context-aware authorization incorporates relevant surrounding facts, such as the represented caller or resource state.

A request can name the ticket. An owner field supplied by the caller isn't proof that the ticket belongs to that person.

Explore Dome: Authorization · Docs: Govern per end user.

Decide what the gateway and backend should check

For a ticket-closure request, the gateway can check whether the agent is approved to call the tool. The ticket service can check whether the employee owns that ticket and whether it is still open. Each uses information available where the check runs.

Read ticket ownership from a trusted source, not an owner field supplied by the caller. If the gateway uses a copy of that information, define how it is verified and kept up to date.

A ticket may close after the agent reads it. The ticket service should check the current state as part of the update, rather than relying on that earlier read.

Explore Dome: Tool Gateway · Docs: Tools gateway.

Define expected decisions

For the hypothetical closure operation, specify expected outcomes before implementing the rule:

• Approved agent, verified employee, owned open ticket: allow if all other required conditions hold.
• Same request targeting another employee's ticket: deny.
• Missing represented-user identity: deny when delegation is required.
• Already-closed ticket: follow the backend's defined state-transition behavior.
• Caller supplies a false ownership field: do not let it override the authoritative record.

Permission to close a ticket doesn't tell you whether it closed. Check the backend result, including any earlier attempt, before retrying.

Dome's rules can evaluate configured conditions on governed calls. Use runtime policy enforcement to locate the component that carries out the decision and ABAC versus RBAC to choose a policy model. For each condition, identify the system that can supply a trustworthy answer.

Explore Dome: Authorization · Docs: Authorization model.