Access, Capability, Permission, Authority, and Responsibility Are Different Things

The five relationships

The differences can be expressed compactly:

• Access concerns reach.
• Capability concerns technical ability.
• Permission concerns what is allowed.
• Authority concerns who may decide or approve.
• Responsibility concerns who has accepted or been assigned the work and its continuing obligations.

These relationships often overlap, but overlap should not be mistaken for equivalence.

The exact source of permission or authority depends on the setting. A small editorial team, regulated organization, software project, public agency, and personal website may establish these relationships differently.

The general distinction remains useful across those settings: being able to act is not the same as being allowed to act, and being allowed to act is not always the same as being authorized to decide.

Why these relationships are not a simple sequence

Access, capability, permission, authority, and responsibility may appear to form a path:

reach the resource
→ perform the action
→ be allowed to act
→ decide what should happen
→ own the follow-through

That path can help identify the questions, but it should not be treated as a universal hierarchy or maturity ladder.

The relationships can be distributed among different participants.

For example:

• A department leader may have authority to approve publication but no access to the content management system.
• An editor may have permission and capability to revise a draft but no authority to approve a disputed factual claim.
• A developer may be capable of deploying software but permitted to do so only after another role authorizes the release.
• An external reviewer may be responsible for checking accessibility while having read-only access to the staging environment.
• An automated connector may have technical access to an external service while the workflow permits it to perform only a narrow set of operations.

Good governance does not require one person to hold every relationship. It requires the distribution to remain understandable enough that the work can proceed without silently converting technical availability into authorization.

Access: reaching the resource

Access concerns whether a person or system can reach a file, interface, database, service, environment, account, or other resource.

Access may be:

• read-only or writable;
• temporary or continuing;
• direct or mediated through another system;
• limited to a particular environment;
• restricted to certain records, folders, pages, or operations;
• dependent on credentials, network conditions, location, or device configuration.

A person who can view a draft has access to the draft. That does not necessarily mean the person can edit it, approve it, publish it, share it, or use its contents for another purpose.

Access may also be insufficient for an assigned responsibility. A person asked to review a page cannot perform a meaningful review if the staging environment is unavailable to them, the required assistive technology cannot reach it, or the evidence needed for the decision is stored elsewhere without an authorized route to it.

Access design therefore has two sides:

• preventing unnecessary or inappropriate access; and
• ensuring that people with legitimate responsibilities can reach what their work requires.

Restricting access can protect a system. Restricting it without considering the work can also produce hidden dependencies, unsafe credential sharing, incomplete review, and responsibility that cannot be fulfilled.

Capability: being technically able to act

Capability concerns whether an action can technically be performed.

A capability may come from:

• a button or control in an interface;
• an account role;
• a command-line tool;
• an API operation;
• a connected service;
• software knowledge or professional skill;
• an automated workflow;
• physical possession of a device or record.

Access and capability are related but not identical.

A person may have access to a repository but lack the capability to merge into a protected branch. A reviewer may open a document but be unable to edit it. An API connection may reach an external platform while supporting only retrieval, not modification.

The reverse problem also matters: a system may expose capabilities broader than the current task requires. A publishing account may support editing, deleting, changing user roles, installing software, and publishing content even when the person is present only to correct one paragraph.

The presence of a capability does not explain whether it should be used.

This distinction is especially important in automation. A connector’s documentation may list all operations the integration can perform. That technical surface does not grant an automated workflow independent permission to call every operation. The workflow still needs an authorized purpose, appropriate scope, and any required human confirmation.

Connectors link workflows to external systems. They should not be interpreted as unrestricted grants of authority merely because a connection succeeds.

Permission: whether the action is allowed

Permission concerns whether a particular action is allowed under the relevant rules and conditions.

Permission may depend on:

• the person or system performing the action;
• the resource involved;
• the type and consequence of the action;
• the purpose for which access was granted;
• the environment in which the action occurs;
• whether required review or approval has occurred;
• whether consent remains present;
• the time, scope, or conditions attached to the permission.

Permission is often more specific than general access.

A person may be allowed to edit drafts but not publish them. A support specialist may be permitted to view account information when responding to an active request but not to use that information for unrelated analysis. A deployment system may be permitted to update a staging environment automatically while production deployment requires confirmation.

System permissions can help enforce these boundaries, but interface controls do not always represent the complete permission structure. A technically available action may still be disallowed by policy, agreement, consent, professional responsibility, or the conditions of the present task.

Permission should therefore be communicated through both architecture and working practice. Where possible, systems should avoid exposing unnecessary capabilities. Where technical restriction is impractical, the workflow should still make the applicable boundary explicit.

Authority: deciding or approving what should happen

Authority concerns who may make or approve a consequential decision.

Examples include authority to:

• approve a public claim;
• authorize publication;
• accept a contractual commitment;
• change access rights;
• approve a deployment;
• delete or replace an authoritative record;
• accept a known risk or unresolved limitation;
• decide that evidence is sufficient for the intended action.

Authority may belong to a person, role, group, governing process, or external institution. It may also be limited by subject, amount, environment, duration, or consequence.

The person with authority does not necessarily perform the resulting action.

An editor may approve an article while a publishing specialist enters it into the content management system. A product owner may authorize a release while a deployment process executes it. A business owner may confirm a service-area claim while a writer revises the page.

This separation can be useful. It allows decisions to remain with the person who has the appropriate knowledge or mandate while execution remains with the person or system equipped to perform it.

The boundary should still be visible. An executor should be able to determine that authorization occurred, what it covered, and whether the artifact or conditions have changed since approval.

Authority is also not created by documentation alone. Writing that someone approved a decision does not make the statement true. A task note cannot retroactively grant authority to its writer, and a handoff cannot silently transfer decision rights merely by naming a next action.

Responsibility: owning the work and follow-through

Responsibility concerns who has accepted or been properly assigned a task, review, decision, or continuing obligation.

Responsibilities may include:

• preparing a draft;
• checking evidence;
• reviewing an implementation;
• requesting missing information;
• performing an authorized action;
• observing the result;
• verifying that the intended task was completed;
• maintaining the artifact after publication;
• escalating conditions that exceed the assigned scope.

Responsibility should not be inferred merely because a person is nearby, has access, or performed similar work before.

Writing a person’s name into a task record does not notify them, secure their agreement, give them the required access, or establish that they have authority to act. A responsible assignment needs an appropriate process of acceptance or allocation.

Responsibility also requires workable conditions. A person cannot reasonably be expected to verify a production result if they cannot access the production environment. A reviewer cannot confirm a factual claim without the relevant source. An editor cannot complete publication if approval remains unresolved.

Where responsibility is present but access, capability, permission, or authority is missing, the workflow has an actionable governance problem. The answer is not necessarily to give one person unrestricted control. It may be to provide bounded access, recruit another role, obtain approval, clarify the next crossing, or place the work on hold.

How the distinctions appear in working systems

Editing and publishing a web page

A writer may have access to a draft and permission to revise it. The writer may not have authority to approve a legal or factual claim. An editor may hold that approval authority. A publisher may then be responsible for entering the approved version into the content management system.

If the publisher’s account exposes a Publish button, the button establishes capability. It does not prove that the current draft was approved or that the publisher is authorized to release this particular version.

The workflow should preserve the relationship among:

• the artifact that was reviewed;
• the decision that was made;
• the scope of the approval;
• the person or system permitted to execute publication;
• the responsibility to verify the public result.

Software deployment

A developer may be technically capable of deploying a change. Branch protection, organizational policy, or release procedure may require another person to approve it.

The deployment system may have access to production and the technical capability to replace the running software. Its permission may be limited to approved releases. The release manager may have authority to authorize deployment without personally running the deployment command.

After execution, another responsibility remains: checking whether the intended version reached the correct environment and behaves as expected.

A completed command does not by itself prove successful task completion.

Changing account permissions

An administrator may have the capability to grant broad access. The current request may authorize only a narrow role change. The administrator is responsible for executing the approved change accurately, not for independently expanding the recipient’s privileges.

The person requesting access may be responsible for explaining the business need without having authority to approve the request. The approving role may authorize the change while lacking direct access to the administrative interface.

The record should preserve what was requested, what was approved, who approved it, what was changed, and whether the resulting access matches the authorized scope.

External connectors and automation

A connector may technically support reading, creating, updating, and deleting records. The workflow may permit only retrieval and draft creation.

Connection success establishes that the system can communicate with the external service. It does not establish permission to use every exposed operation. It also does not establish that an automated result should be accepted without review.

Automation boundaries help distinguish work that may proceed automatically from decisions or actions requiring inspection, confirmation, approval, or direct human control.

What interfaces should communicate

Interfaces often blur governance relationships because they show what is technically available without explaining why, when, or by whom the capability should be used.

A control labeled Publish, Delete, Deploy, Approve, Send, Purchase, or Change permissions may expose a consequential capability. The interface should help the person understand the action’s destination, scope, conditions, and expected consequence before execution.

Depending on the risk and context, an interface may need to communicate:

• which artifact or record will be affected;
• which environment or destination is involved;
• whether the action is reversible;
• which role is currently acting;
• whether approval is required and whether it has been recorded;
• what the present authorization covers;
• which state was reviewed or approved;
• what will happen immediately after confirmation;
• how the result will be observed and verified.

Not every ordinary edit needs a complex approval interface. Governance should remain proportionate to consequence.

The stronger controls belong where an action could publish, send, delete, deploy, purchase, expose information, change rights, create commitments, or replace an authoritative record.

Confirmation should not be decorative. A confirmation step earns its place when it helps the person inspect and deliberately choose the actual consequence.

The path may be understood as:

prepare
→ inspect
→ confirm authority
→ authorize
→ execute
→ observe
→ verify

These stages may be combined in a simple workflow, but combining them should not make their meanings disappear.

Preserving the distinctions in handoffs and records

A workflow handoff should help the next participant understand not only what remains to be done, but which relationships govern the next action.

Useful statements include:

• Access: The reviewer can open the staging page but does not have access to production settings.
• Capability: The publishing account can publish and unpublish pages.
• Permission: The account may be used for publication only after editorial approval.
• Authority: The managing editor retains authority to approve publication.
• Responsibility: The publishing specialist has accepted the task of entering the approved article and verifying the public page.

The handoff records these relationships. It does not create them merely by stating that they exist.

If responsibility has not been accepted, the record should say that ownership remains unresolved. If authority is unclear, the task may need to pause rather than converting uncertainty into implied approval. If the named participant lacks access, the next action may be to provide an authorized route to the material or recruit someone who already has appropriate access.

Decision records, approval records, handoffs, and system logs may each preserve different evidence:

• A decision record explains what was decided and within what scope.
• An approval record establishes that an authorized approval occurred.
• A handoff locates the task and its next action.
• A system log may show that an operation was attempted or completed.

None of these records should silently claim the work of all the others.

Access and authority in AI-assisted work

AI-assisted workflows make these distinctions especially important because a model may participate in research, drafting, transformation, classification, tool use, or workflow coordination without owning the decision or outcome.

An AI system may receive access to:

• a main artifact;
• supporting documents;
• retrieved sources;
• a content platform;
• a database;
• a connected external service;
• tools that can create or modify records.

That access does not automatically establish permission to use every part of the supplied context for every purpose. It also does not grant authority to publish, send, delete, deploy, approve, purchase, or change permissions.

The workflow should distinguish:

• providing material for analysis from authorizing external action;
• generating a draft from accepting the draft;
• suggesting a decision from making the decision;
• having a tool available from being permitted to invoke it;
• successfully invoking a tool from verifying the intended outcome;
• retaining context from establishing that the context remains current and relevant.

Human review should also be meaningful. A person asked to approve an AI-assisted result needs access to the relevant artifact and evidence, enough information to understand known uncertainty, and the authority to affect what happens next.

An approval button placed after an opaque automated process does not create responsible oversight by itself.

The person or organization deciding how generated material is used retains responsibility for consequential use. AI assistance may contribute language, analysis, or tool activity without becoming the approving authority or the owner of the result.

Questions for workflow design and review

When a workflow includes consequential actions, ask:

Access

• Who can reach the relevant artifact, environment, evidence, or system?
• Is access read-only, writable, temporary, or continuing?
• Can the person responsible for the task reach what the task requires?
• Does the access expose unnecessary information or functions?

Capability

• What actions can each person, account, connector, or automated system technically perform?
• Does the available capability exceed the present task?
• Can unnecessary capabilities be restricted or separated?
• Could a visible control be mistaken for permission or approval?

Permission

• Which actions are allowed, by whom, for what purpose, and under what conditions?
• Does permission depend on prior review, consent, or approval?
• Is the permission limited by artifact, environment, time, or consequence?
• How will the participant know when permission is absent or has expired?

Authority

• Who may make or approve the relevant decision?
• What is the scope of that authority?
• How is authorization communicated to the person or system executing the action?
• What should happen if the artifact or conditions change after approval?

Responsibility

• Who has accepted or been properly assigned the next action?
• Does that participant have sufficient access, capability, and permission?
• Who observes and verifies the result?
• Who maintains the artifact or responds if the action produces an unexpected outcome?
• Where should unresolved ownership be made visible?

The goal is not to add approval ceremony to every ordinary action. It is to prevent technical availability, organizational assumption, and vague task language from silently substituting for permission, authority, or accepted responsibility.

Keep the differences visible

A person may have access without capability. A system may have capability without permission. A person may have permission to perform an action without authority to decide that the action should occur. Another person may hold decision authority while someone else carries responsibility for execution and verification.

These arrangements are not inherently flawed. Many reliable systems depend on them.

The governing question is whether the relationships remain clear enough for people and systems to know:

• what they can reach;
• what they can technically do;
• what they are allowed to do;
• what they may decide or approve;
• and what work they have actually accepted responsibility for carrying forward.

When those distinctions remain visible, access can support work without becoming silent authority. Capability can remain useful without becoming uncontrolled action. Responsibility can be assigned without leaving someone unable to fulfill it.

The result is not governance through unnecessary restriction.

It is governance through understandable relationships.