Who can use AgentLinkOps today, and what happens to your data.

Who can use it today

Hosted access is invitation-only. There is no public signup, no purchase path and no price that can be charged: payment collection does not exist in this build, and the checkout call answers available: false with that reason. Reading the public brief, the tool catalog or this page creates no account and starts no monitoring.

Inside an invited workspace, a member with write access can invite another person by email as an admin, member or viewer, optionally limited to named projects. The invitation returns a join token once; only its hash is stored, and the accepting person’s verified email must match the invitation, so a forwarded link cannot admit a stranger. An invitation can never grant a role or a project the inviter does not hold. AgentLinkOps does not send the invitation email; the inviter hands the token to the person.

One tool needs no account: the anonymous free check, served on its own endpoint at app.agentlinkops.com/free/mcp, fetches one supplied source page once and reports whether it links to the destination, with the same four-state honesty as the authenticated verifier and no browser rendering. Its ceilings are three checks per visitor per UTC day, one page fetched per check and a 15-minute result cache, and it never returns raw publisher HTML. The MCP tool catalog shows its state beside every other registered tool.

OAuth scopes and project grants

An agent reaches the service three ways: MCP at /mcp with OAuth approved in your browser, REST under /v1 with a scoped API key, and the local CLI. Every tool is checked against the credential’s scopes on every request, and membership is re-read on every request, so removing someone takes effect immediately. There are eight scopes:

Three ceilings sit on top of the scope list. A viewer role receives only the read scopes. An API key can carry only scopes its owner holds, and a key’s scopes are narrowed again whenever the owner’s role is narrowed. A member’s project grant is the ceiling on every key and every OAuth grant they hold: a key can never widen what its owner may see, and narrowing the member narrows their existing keys at once. A project-restricted credential cannot create projects.

OAuth approval is per client and per workspace, and it is revocable in the workspace. The consent screen names the scopes requested; approving a connection does not grant more than the approving member holds. The agent setup guide shows the approval flow for each tested client.

What is stored

• What you supply. The source and destination URLs you register, expected anchor and rel attributes, project and competitor domains, webhook endpoint URLs, and the rows you import.
• Observations. For every check: state and reason, the final URL after redirects, HTTP status, robots posture, the SHA-256 of the bytes read, the byte count, the fetch time, each occurrence with its anchor and rel tokens, and the standing warning that rendering and visibility were not checked. The hash sits beside the result in every stored row.
• Evidence snapshots. The JSON snapshot of an observation, kept in private object storage and readable through get_link_evidence until retention removes it, after which the call answers EVIDENCE_EXPIRED.
• Events and deliveries. The change feed rows, and diagnostics for each webhook delivery attempt.
• Usage. Reserved, consumed and released check units per UTC month, per workspace.

What is not stored: page HTML in your repository, which the CLI refuses as a contract constant; your prospects, outreach history and combined CRM, which the service has no place to hold; and card numbers, because no payment provider client exists in this build.

Retention windows, as configured

These are the values in the current source. They are configuration, and they change only with a release that changes the configuration.

Archives live outside the prefix that expires, on purpose: nothing durable may sit under a prefix that a lifecycle rule deletes. The reasoning is in the methodology.

What deletion exists today

Two calls remove a resource you created and never ran. preview_resource_deletion reports the rows a removal would touch, the exact confirmation string and any blockers; delete_resource removes the watch, destination or project when the preview shows it eligible, and completed deletion receipts make retries safe. Both need a current writable membership, a matching project grant and the write scope for that resource type.

A resource that has executed checks is blocked, and the blocker says why: its observations, archives or webhook payloads may be shared with other records, and deleting rows while a writer can still run is not erasure. For those, pausing a watch or destination stops future scheduling while preserving the evidence, and retiring a competitor set does the same for competitor work. Historical erasure across writers, retained archives and provider payloads is in progress and not available through these calls yet; the deletion preview says so in its own scope field.

For anything beyond that, including removal of an account, ask the pilot contact described below. The privacy policy states the commitment; this page states what the tools can do today.

How evidence and published contacts are handled

Publisher text inside a snapshot is untrusted data. It is stored so a person or an agent can inspect what the page said at the time; it is never treated as an instruction, and the free check never returns it at all. The observation hash lets you tell whether the snapshot you are reading is the one the check saw.

Published contacts are the email addresses and contact-page URLs a publisher explicitly placed on a page that was saved complete. No address is inferred, deliverability is never checked, and the record says not_checked on every contact. The service never sends outreach and never connects to a mailbox; your agent’s own email tools do that, under your review.

Limits and the meter

Checks are metered in three separate totals: reserved when queued, consumed when the observation is saved, released when a check fails for good or is cancelled. An unknown result still consumes its unit, because the fetch happened. Source checks and destination checks draw on one workspace meter.

Admission is enforced against the workspace’s monthly check limit: new checks stop when consumed plus reserved reach it, released reservations free capacity, and the limit resets on the first of the next UTC month. get_usage returns that enforced limit, what remains of it and the reset time in a check_budget block, with enforced_by: workspace_monthly_check_limit and plan_allowance_enforced: false. Plan allowances appear only in billing estimates, and nothing is charged.

Hosted watches run on a cadence between one hour and 30 days that you choose per watch; the free check has its own daily ceiling, stated above.

Webhook delivery

Deliveries are signed with HMAC-SHA-256, the secret is shown once and can be rotated, and delivery is at-least-once with a resumable feed, so receivers deduplicate by delivery id. Two header names are sent with identical values during the pilot, AgentLinkOps-* and the compatibility Linktrail-* set. The transports for single events and periodic digests exist and are tested; hosted delivery to a customer receiver is gated by environment configuration in the current build.

Leaving is a file copy

The ledger that declares what you expect from each source page is a plain JSON Lines file in your own repository. Cloud sync mirrors it and never writes back into it. What the cloud holds beyond that, you can take out: export_link_watches pages through every monitored placement with its state, over MCP with the export scope or over the REST export route, for local CRM recovery. There is no format that only the workspace can read.

The local CLI can also adopt a SQLite CRM, previewing before it writes and naming every status it treated as active. Keeping a backlink ledger in your repository describes the file, and the bridge page puts the exit story in buyer terms. How your own CRM and sender tools receive a campaign without any vendor connector is on the integrations page.

Where a security question goes

During the pilot, the person who sent your invitation is the contact for security questions, deletion requests and anything this page does not answer. The privacy policy names [email protected] as the interim contact for privacy and deletion requests; that mailbox received and was answered from on September 16, 2026. The [email protected] mailbox is still being set up and is not yet a route you should rely on; this page will name it with the date it was verified.

Never paste API keys, tokens or one-time codes into a conversation with an agent. Approvals happen on the AgentLinkOps authorization screen, and credentials belong in your client’s secret storage.

What this page does not claim

• No price. No number on this site can be charged, and none is published as a rate.
• No certification or audit attestation. None has been obtained, and none is implied by the word “security” in a heading.
• No customer Google Search Console connection. That is planned and not in the source; verification of our own domain is a different thing, and Google’s API has no links-report endpoint either way.
• No availability percentage. Nothing measures availability yet; the status page records the deployed version and how to verify it.
• No open signup, free tier or self-serve plan. The pilot is invitation-only.

How this page was checked

Written September 15, 2026, updated September 16, 2026 against the repository at commit cc2c74f. Each statement quotes a row of the DP-0023 claims ledger: A-03, A-05, A-07, A-10 to A-15, M-04 to M-06, P-01, P-03, P-04, P-06 to P-08, W-07 to W-10. The scope list is read from the shared access vocabulary file, the retention windows from the retention module and the webhook module, the deletion rules from the resource lifecycle module and the meter rules from the usage and billing modules, all on that commit. The suites those rows cite were re-run the same day: authorization 10 of 10, resource lifecycle 17 of 17, retention 18 of 18, webhooks 27 of 27, contacts 3 of 3. The hosted preview and delete calls were exercised against production on September 14, 2026 in a recorded acceptance run, which is the dated evidence behind the deletion section.

A changed source file voids a claim until it is rechecked. If a window or a rule here no longer matches the product, the ledger is where the correction starts.