One domain. One key. One receipt.

A scoped agent key is a narrowly authorized credential that lets an automated agent act on one domain, for a declared purpose, with a verifiable receipt of what was granted and later used. The operating rule is simple: one domain, one key, one receipt.

That rule exists because most agent access today still looks like a reused API token, a shared CMS login, or an unbounded crawl. Those patterns collapse three different jobs—identity, permission, and audit—into one secret. When the secret leaks, every property and every action goes with it.

A citable definition

Scoped agent key: a domain-bound, purpose-limited credential issued to a named automated agent. It authorizes only the actions listed in its scope, works only for a single origin, expires by default, and is paired with a receipt that records issuance, scope, use, and revocation.

One domain, one key, one receipt: a control model in which each agent-to-site relationship gets its own key, that key cannot be reused on another hostname, and every grant or use produces an auditable record.

These are governance terms, not a marketing slogan. They describe how to give an agent just enough access to do a job without turning the site into a shared backdoor.

Why unscoped agent access fails

Teams now let software fetch pages, read sitemaps, inspect structured data, pull Search Console-style signals, draft content, or open tickets. The agent may be an internal copilot, an agency workflow, a vendor connector, or a third-party research bot.

Unscoped access usually fails in the same ways:

• Shared secrets travel. An agency key, CMS app password, or “temporary” token ends up in a chat log, a CI variable, a browser extension, or another client workspace.
• Blast radius is the whole company. One token that works on every brand site, staging host, and admin route is a single point of failure.
• Purpose is implied, not declared. “Read the site” can become “export the site,” “post to the site,” or “call every internal API the cookie can see.”
• There is no receipt. After an incident, nobody can answer who issued access, what the agent was allowed to do, which URLs it touched, or whether the key is still live.

A scoped agent key treats the agent as a principal, the domain as a hard boundary, and the receipt as part of the product—not a log you hope someone enabled.

The three constraints

One domain

Bind the key to a single origin, such as https://www.example.com. Do not let the same secret work on:

• a sister brand
• a staging or preview host, unless that host is the *only* audience
• a wildcard like *.example.com unless every subdomain is truly the same trust zone
• an IP, CDN edge, or admin hostname that was never named in the grant

Domain scoping is not a convenience filter. It is the difference between “this agent may read the public marketing site” and “this agent may act anywhere our TLS certificate happens to cover.”

If a vendor needs access to ten client sites, that is ten keys. Cross-site reuse is how a compromise at Client A becomes an incident at Client B.

One key

Issue a unique key for each tuple of:

• agent identity (the software or workflow, not “marketing”)
• operator (the human or organization responsible for that agent)
• domain
• purpose (for example: read public URLs and sitemap; do not write)

Do not mint one “platform key” and hand it to every connector. Do not rotate by emailing the same secret to a new vendor. When an engagement ends, revoke that one key. The rest of the site’s agent relationships stay intact.

One key also makes least privilege practical. A research agent that only needs canonical URLs and robots.txt should not hold the same secret as a publishing agent that can create drafts.

One receipt

A receipt is the durable record that makes the key trustworthy to a security team, a client, or a later incident review. At minimum it should capture:

A receipt is not “we have application logs somewhere.” It is a record you can show: this agent was allowed to do X on this domain, it did Y, and the grant is now closed.

What “scope” should actually list

Scope should be written so a human and a policy engine read the same thing. Vague scopes recreate the shared-password problem.

Useful scope dimensions:

• Actions: read versus write versus delete. Most AEO and research agents need read only.
• Surfaces: public HTML, sitemap, robots.txt, feeds, specified JSON endpoints. Exclude /wp-admin, billing, identity, and unpublished drafts unless that is the job.
• Methods: GET and HEAD are a different world from POST, PUT, and PATCH.
• Rate and volume: requests per minute and a daily URL or byte cap.
• Data class: public pages only; no form submissions, no customer records, no private Search Console exports unless separately granted.
• User-agent and key presentation: the agent must identify itself and send the key only on the approved origin, preferably in a dedicated header rather than a cookie jar.
• Lifetime: hours or days for experiments; a short renewable window for production jobs. Renewal should mint a new key ID and a new receipt, not silently extend a forgotten secret.

If you cannot write the scope in one short paragraph, the agent is asking for too much.

How this differs from a normal API key

A typical API key proves that *someone* who holds the string may call *some* service. A scoped agent key adds constraints that ordinary keys often skip:

1. Audience restriction to one site origin, not “the API.”
2. Agent binding so the caller is a named bot, not an anonymous script.
3. Purpose binding so unused privileges do not exist.
4. Receipts for both the grant and the traffic.
5. Independent revocation without rotating every integration at once.

You can implement those properties with OAuth access tokens, signed JWTs, mutual TLS, or a site-issued capability token. The mechanism matters less than the invariants. If any invariant is missing, it is just another secret.

Hypothetical: an agency research agent on one marketing site

Hypothetical scenario, not a customer story. An agency wants an internal agent to inventory indexable URLs, titles, canonicals, and existing schema on https://www.example.com so analysts can brief an AEO program.

A scoped grant would look like this:

• Subject: agency-url-inventory-agent operated by the agency’s technical SEO lead
• Audience: https://www.example.com only
• Scope: GET/HEAD on public URLs listed in the sitemap plus /robots.txt and /sitemap.xml; no authenticated app routes; no write
• Limits: 60 requests per minute, 10,000 URLs per day
• Lifetime: 7 days, renewable after a human review
• Receipt: issue record plus a daily use summary of URL count, status-code mix, and peak rate

What this grant refuses:

• the client’s second brand domain
• staging (https://staging.example.com)
• CMS write access “in case we need to fix a title”
• reuse of last quarter’s token because “it still works”

If the agent later needs to draft on-page recommendations inside a workspace, that is a different product surface and a different key. Fetching the public site and changing the public site are not one job.

What belongs on the site versus in the vendor

Site owners still need public, keyless rules for open crawlers: robots.txt, crawl-delay or rate expectations, and any published agent guidance they maintain. A scoped agent key does not replace those files. It covers the narrower case where an agent is *invited* to do more than an anonymous crawler should do, or where the owner wants attribution and a kill switch.

A practical split:

• Anonymous crawlers: public cacheable pages only; identify yourself; obey robots; no privileged endpoints.
• Invited agents: scoped agent key; named operator; receipt; rate contract; revocation path.
• Humans and admins: SSO, roles, and phishing-resistant MFA. Do not put people on agent keys, and do not put agents on human passwords.

If a vendor cannot accept a domain-scoped, expiring key, they are asking you to outsource your trust boundary.

Why this matters for AEO, GEO, and AI visibility work

Answer engines and AI assistants increasingly summarize brands from crawled pages, retrieved passages, and third-party tools. Visibility work therefore includes both what the site says and which machines are allowed to read or represent it.

Scoped agent keys help that work in concrete ways:

• Attribution. You can tell an invited research agent from an unknown scraper.
• Cleaner evidence. AEO briefs should be based on the live public site, not on a stale export sitting in a shared drive. A short-lived read key makes “go fetch the current page” a controlled action.
• Safer agency access. Multi-client teams should not hold a master token that can read or alter every property they have ever touched.
• Incident containment. If an agent misbehaves or a laptop is lost, you revoke one key ID and keep the rest of the measurement stack running.
• Honest scope for write tools. Anything that can publish, inject structured data, or open PRs needs a tighter key and a louder receipt than a read-only inventory job.

This is adjacent to technical SEO and AI visibility, not a replacement for them. Canonicals, status codes, internal links, and extractable definitions still decide whether an answer engine can cite you. Access control decides whether the machines collecting that evidence were supposed to be there.

Teams that want the measurement and publishing workflow without turning every connector into a superuser should start from the same principle iSEOup uses across SEO, AEO, and GEO: make the site understandable to machines, then keep machine access explainable to humans. The AI visibility and technical SEO surfaces are where those two jobs meet. For the operating model, see how it works.

How to issue a scoped agent key without building a lab

You do not need a research-grade crypto stack on day one. You do need a written grant and a revocation path.

1. Name the job in one sentence. Example: “Read public URLs to extract titles, canonicals, and FAQ schema.”
2. Name the origin. One scheme + host. Include the www versus apex choice explicitly.
3. Deny by default. List allowed paths or path prefixes. Everything else is closed.
4. Mint a unique key ID and secret. Store the secret in a vault. Put only the key ID in tickets and chat.
5. Write the receipt before you send the secret. If the grant is not written down, it is not scoped.
6. Set expiry when you issue, not after a scare. Calendar the review.
7. Log use against the key ID. URL, method, status, user-agent, and source IP are enough to start.
8. Revoke on completion, vendor change, or scope change. Scope change means a new key, not an edited spreadsheet row.

Agencies can apply the same checklist per client property. A useful internal rule: no key leaves the vault unless its receipt is filed next to the SOW. That habit is more valuable than a long policy PDF. Agency-specific operating context lives on iSEOup’s agency solutions page; the principle above is the access-control half of that operating discipline.

Failure modes to refuse

• Wildcard keys for “all our properties.”
• Browser cookie passthrough, which quietly inherits a human’s session.
• Long-lived keys in prompt text or in an agent’s system instructions.
• Write scope “just in case.” Add write when there is a ticket, a reviewer, and a rollback.
• One receipt per vendor, not per key. Vendor-level paperwork does not tell you which bot hit /checkout.
• Silent impersonation of Googlebot or a major assistant. Invited agents should use their own product name plus the key ID.

FAQ

What is a scoped agent key?

It is a credential that authorizes a named automated agent to perform a listed set of actions on a single domain, then expires and can be revoked. The grant and the traffic should both leave a receipt.

Is a scoped agent key the same as an API key?

Not necessarily. An API key is only a secret. A scoped agent key is a secret plus audience, purpose, lifetime, agent identity, and an audit record. Some API keys can be *made* into scoped agent keys if those constraints are enforced.

Why one domain instead of one account?

Accounts often span brands, environments, and admin tools. A domain is the public trust boundary users and crawlers already understand. Binding to one origin keeps a leak from crossing properties.

Can two agents share one key if they do the same job?

No. Shared keys destroy attribution. If one agent is buggy, you cannot revoke it without blinding the other, and the receipt cannot say which process misbehaved.

What should a receipt include at minimum?

Issuer, agent name, responsible operator, origin, scope, issue time, expiry, key ID, and later use or revoke events. A signed or hashed issue record is better than an editable wiki page, but a complete written grant is better than nothing.

Do public answer-engine crawlers need a scoped agent key?

Usually no. Public crawlers should use the site’s open rules and public pages. Use a scoped agent key when you *invite* an agent, grant non-public surfaces, need a contract on rate and purpose, or need a kill switch tied to a vendor.

How does this relate to robots.txt or published agent files?

Those files publish standing rules to the open web. A scoped agent key is a private, revocable exception or invitation. Keep the public rules conservative; put extra access in keys, not in a wider robots allow.

How long should a scoped agent key live?

As short as the job allows. Inventory and research jobs can live days. Continuous monitoring can live in short renewable windows. Avoid keys with no expiry. Renewal should create a new key ID and a new receipt.

What is the next action if we are using agents in SEO or AEO work?

Write the access grants you already have: which bots, which domains, which secrets, which expiry. Replace shared logins with domain-scoped read keys where you can. Then make sure the pages those agents fetch are actually citable—clear definitions, stable URLs, and machine-readable structure. iSEOup’s AEO software overview and solutions pages outline that visibility work; pricing is the place to check current packaging before you commit a stack. [VERIFY: confirm current product names, packaging, and whether iSEOup issues or manages scoped agent keys as a platform feature before implying product support.]

Internal link suggestions

• SEO, AEO, and GEO — pair access control with the optimization model agents are trying to read.
• How it works — show the operating loop after the key and receipt are in place.
• AI visibility — connect invited-agent evidence collection to how brands appear in answers.
• Technical SEO — keep crawl, canonical, and extractability work in the same conversation as agent access.
• AEO software — next step for teams operationalizing answer-engine visibility.
• Agency solutions — multi-domain key hygiene for client portfolios.
• Blog — related implementation notes as they are published.

The rule stays small enough to remember in an incident channel: one domain, one key, one receipt. If a request needs more than that, it needs another grant—not a wider secret.

SEO Notes

Meta title: Scoped Agent Key: One Domain, One Key, One Receipt

Meta description: A scoped agent key binds one AI agent to one domain and a written receipt. Learn the definition, scope fields, and how to issue revocable access.