Backlink API permissions and scoped access

Backlink API permissions should match the work you want an agent to perform. An agent reviewing saved records needs less access than one requesting checks or changing a monitoring schedule. Restrict both the kinds of actions it can take and the projects it can reach.

AgentLinkOps uses named scopes and project grants. This article describes the vocabulary reviewed on September 12, 2026. Account setup and hosted feature availability are separate from the permissions described here. Check the connected environment before granting access for a recurring job.

Separate authentication from permission

Authentication identifies the caller. Permission determines which actions that caller may perform. A valid token can still receive an access error when it lacks the scope required by a request.

MCP authorization describes authorization for HTTP-based MCP connections. AgentLinkOps also supports scoped API credentials for its service. Keep each credential attached to its intended endpoint and workflow; do not assume a credential accepted by one transport is interchangeable with another.

An agent's written instruction adds a further boundary. A token that can change watches does not mean the user approved changing every watch. The technical scope places a ceiling on access, while the task describes the work authorized for this run.

Start with saved-data reads

For a research review, choose the read scopes required by the actual tools. The current vocabulary includes:

Scope	What the name covers
projects:read	Accessible projects and workspace context
watches:read	Saved monitoring records and observations
events:read	Recorded changes and feed reads
discovery:read	Stored discovery and competitor research records

These scopes do not grant project creation, watch changes or new discovery requests. A viewer role receives read scopes in the reviewed role mapping. The service still checks membership and the caller's project grants.

Suppose an agency asks an agent to review evidence for one client. A project-restricted credential is a better fit than broad workspace access. The agent should confirm the project identifier in its report, especially when several clients have similar names or related domains.

Add write access only for a named task

The remaining scope vocabulary includes projects:write, watches:write, discovery:write and exports:create. Each grants a different class of work. Export creation has its own scope, so a consumer recovering an expired event feed may need access beyond ordinary event reads.

A selected candidate check illustrates why one request can need multiple scopes. In the reviewed MCP contract, verify_discovery_candidate needs discovery:read to access the candidate and watches:write to request the check. Read-only access to candidates is insufficient.

An import into stored discovery uses discovery:write, even though it uses an export the customer already owns. A request can change stored data without purchasing a supplier query. Keep those distinctions in your run notes so “write” does not become a vague synonym for “spend.”

The MCP workflow article shows how to read candidates first and request selected checks later. It also explains why a candidate's presence is separate from verification.

Scope access to the right projects

A project grant narrows the set of records a caller can reach. It does not add action permissions. Conversely, adding a scope does not make an inaccessible project available.

The current service rejects project-restricted access that also asks to create projects. That follows the distinction between working within named projects and creating a new project whose grant does not yet exist. Let an account owner handle that setup step through an authorized workflow.

When access fails, read the error and compare the requested action, scope and project grant. Do not respond by granting every scope until the request works. The smallest correction is easier to review and easier to revoke later.

Keep credentials out of link records

Store secrets through the credential mechanism approved for your environment. The backlink ledger should hold source URLs, targets and references, not tokens. Avoid pasting credentials into prompts, report screenshots or committed configuration.

Use a separate credential when a scheduled consumer has a narrower job than an interactive agent. When that job ends, revoke its access rather than relying on the agent to remember an old instruction. The local ledger guide describes which files own intent and observations.

For each run, record the account, project, intended actions and resulting changes without recording the secret itself. Agent approval boundaries explain when a capable agent still needs a concrete user decision. The workflow hub connects permissions to the broader discovery and monitoring sequence.

Sources

1. Authorization · Model Context Protocol · 2025-11-25