DoReply
Learn the system

Safety, permissions, and accountability

See how roles, agent ceilings, secrets, network controls, approvals, and records combine to bound real work.

Delegate treats safety as a set of enforceable boundaries around useful work. No single setting carries the whole burden. Identity, permissions, agent configuration, credentials, network policy, approvals, and work records narrow what can happen together.

Compare the team's Roles with the selected agent's authority settings while reading this page.

People receive scoped roles

Built-in roles cover Administrator, Manager, Contributor, Viewer, and Billing responsibilities. Custom roles can express a different division of duties. Permissions distinguish viewing, editing, and managing resources and can apply at team or project scope.

Give people the access their work requires. This also bounds the agents they delegate to.

Agent authority is an intersection

An agent has a permission ceiling: the most its job is ever allowed to do. For a specific run, its effective authority is that ceiling intersected with the delegating human's permissions. Project scope and available tools narrow it further.

A ceiling is not a grant. Raising it cannot give the agent an ability its delegator lacks. This prevents a person from escalating their own access by asking a broadly configured agent to act for them.

Secrets stay behind a brokered boundary

Secrets are write-only after entry and bound to an intended destination. When an approved tool needs one, the credential broker supplies it to that request and removes sensitive values from observable output. The agent should not need to read or repeat the raw secret.

Grant the destination and operation the work requires, not a general-purpose credential path. Rotate or revoke the secret at its source when its ownership or intended use changes.

Network access is a policy choice

An agent's workspace can use an allowed network preset, request approval for a new destination, or operate without outbound access. Destination validation and threat filtering reduce the risk that an apparently useful page or instruction redirects work somewhere unsafe.

Approvals guard consequential boundaries

Some actions pause for a person with the relevant authority. The request appears in context so the reviewer can see the card, agent, intended action, and reason. Approve or deny the specific request; do not treat approval as a blanket endorsement of the run.

Not every agent step needs approval. Routine operations can proceed when they are already inside policy. Working style may add more review points, but it never removes a required safety decision.

Accountability stays attached to the work

The work stream records the delegator, agent, messages, important actions, approval decisions, outputs, lifecycle, and cost. Team and project controls show who can configure access and spending. Together, these records let a reviewer reconstruct the meaningful chain from request to result.

Next steps