FAISC

In plain English

More of your customers may start sending an AI assistant to your website to do things for them. FAISC is our proposal for letting that happen safely: the customer connects their own assistant to their own account on your site, and switches on, in their account settings, exactly what it may do, such as placing an order or replying to a message. The assistant can never do more than the customer could do themselves, everything it does is logged under the customer's account, and one switch turns it off. You keep your doors open to these visitors without handing control to bots.

Abstract

We expect many people to reach websites through a personal AI agent rather than a browser they drive themselves. Websites often answer that change in one of two ways, and both fall short. The first is the bot wall: block automated visitors and keep the human web human-only. The second is the developer-integration model: API keys and fixed scope catalogues, designed for companies integrating with companies, handed to consumers who cannot evaluate them.

This report specifies a third model, which we name FAISC. Under it, a person's agent attaches to that person's own account on a website and may act inside the site, not merely read it, under two bounds set by the person: the capabilities the person has explicitly switched on for their agent in their own account settings, and the person's own permission level on that site, which forms an absolute ceiling the agent can never exceed. The agent is FAISC-connected: a delegate whose authority is a person-granted, revocable, strictly attenuated subset of the authority of the human it serves.

We propose this model as a standard way for websites to relate to personal agents, and we expect it, or something very like it, to become one, for one structural reason: it puts the switches in the hands of the only party whose consent actually legitimizes the delegation, the account holder, using controls that already exist in a place the account holder already understands: their settings.

1. The problem

1.1 The bot wall fails the site's own customers

Some of a website's legitimate visitors can arrive as agents acting for people the site would welcome in person. A gate that cannot distinguish "a person's agent, sent by an account holder in good standing" from "a scraper" can refuse the site's own customers at the door. Our position since 2026-10-27: gating automated access wholesale puts an online business at risk in the agent era.

1.2 Scraping fails everyone else

Where no sanctioned channel exists, capable agents read websites the way they read everything: by rendering pages built for human eyes and inferring structure. The result is inaccurate data for the visitor, load and defensive cost for the site, and no consent, attribution, or revocation anywhere in the loop.

1.3 Fixed scope catalogues fail the consent test

The incumbent technical answer, the site publishes a fixed menu of scopes; the agent requests some; a consent screen shows the list once, was designed for developer integrations. For a personal agent it has three defects:

• The menu is the site's, not the person's. Granularity is whatever the site chose to expose, identical for every user, and unintelligible to most of them ("read:services" is not a sentence a person can weigh).
• Consent is a moment, not a control. A one-time approval screen gives the person no ongoing surface where the delegation lives, can be inspected in plain language, and can be narrowed as easily as it was granted.
• It stops at reading. Fixed catalogues in consumer products are often read-only, because a site cannot responsibly pre-authorize actions for strangers. So the agent can look but not do, a brochure, not a door.

2. Definition

FAISC is a delegation model for personal agents on account-based websites, defined by three laws. The name states the viewpoint: from the site's side of the glass, a visitor's personal agent is a foreign AI agent, software the site does not own, arriving on behalf of someone the site does know. FAISC is the set of connectors a site provides so that foreign AI agent can be attached to its human's account, granted capabilities, and governed.

1. Attachment. The agent attaches to the account holder's own login on that site. It does not hold an independent account, an independent identity on the site, or a standing relationship with the site apart from the person. Where the person goes, the attachment does not automatically follow: attachment is per-site, established separately on each site.
2. The Settings Grant. What the agent may do is granted by the account holder, capability by capability, inside the account settings of that site, the same surface where the person already manages their account. A capability the person has not switched on does not exist for their agent. Switching it off revokes it.
3. The Ceiling (attenuation). The agent's authority is a subset of the account holder's own permission level on that site, and can never exceed it. Settings can only offer capabilities the person themselves holds. A member cannot grant their agent moderation powers; a customer's agent cannot reach staff functions; no grant, bug, or request can raise an agent above its human.

An agent acting under this model is a FAISC-connected agent. The account holder remains the principal: every action the FAISC-connected agent takes is, in law-like terms the site's records should mirror, an action of the principal, taken by their delegate, inside their grant.

Corollaries

• Per-site containment. A FAISC-connected agent's authority begins and ends at the one site's boundary. Attachment on one site confers nothing on any other site, and nothing at all on any internal or operator system of the site's owner.
• Detach is total. The account holder can detach the agent entirely, or the site operator can suspend agent access site-wide, without affecting the person's own account or the human website.
• Attribution is intrinsic. Because the agent acts inside the principal's account, every action is attributable to that account and marked as agent-taken. Anonymous agent action is not a feature of the model.

3. How it works

3.1 Lifecycle

1. Account. The person holds an ordinary account on the site, with an ordinary permission level (member, customer, staff, administrator, whatever the site's roles are).
2. Attach. The person attaches their agent to the account, from inside their authenticated settings. Attachment is an act of the human session only; an agent cannot attach itself, and no agent credential can create, renew, or widen an attachment.
3. Grant. In the same settings surface, the person sees the site's agent capabilities in plain language, "Your agent can make posts", "Your agent can place orders", "Your agent can reply to messages", each bounded by their level, and switches on the ones they want. Nothing is on by default.
4. Act. The agent works in the site's backend as the person: reading and acting only through granted capabilities, enforced by the server on every request, never by the agent's say-so.
5. Audit. The person can review what their agent did, in the same settings surface, in plain language, with timestamps.
6. Revoke. Flipping a capability off ends that power immediately. Detaching ends all of it. Changed passwords and closed accounts detach automatically.

3.2 A worked example

A social site run under this model offers members the capability make posts. Alice, a member, attaches her agent and switches it on in her settings. Her agent can now publish posts as Alice, Alice could do that herself; the ceiling holds. It cannot delete other members' posts (Alice cannot), cannot change Alice's password or email (no such capability may exist, see §5.3), and cannot alter its own grants (grant changes are human-session-only). When Alice switches the capability off, the next attempted post is refused, and the refusal is logged.

4. Lineage: from Connect Your Agent v1 to FAISC

Project Moosed shipped the predecessor of this model on 2026-10-27 as the Connect Your Agent standard: a public manifest, a visitor-confirmed registration funnel, hash-stored revocable credentials, and a catalogue of three read-only scopes, governed by a least-privilege security review whose headline rule (R1) was that an agent credential can never confirm, renew, or widen its own grant.

V1 established the consent rails, human-as-grant, revocation with immediate effect, append-only audit, an operator kill switch, and v1's restriction to reading was deliberate for a first ship. FAISC keeps every one of those rails and changes what limited v1:

5. Requirements for a conforming implementation

A site claiming FAISC conformance:

5.1 Must

1. Bind attachment to the human's authenticated session. Attachment, grant changes, and detach are performed by the account holder in a logged-in human session. An agent credential is refused at every grant-altering endpoint (the R1 rule, carried forward from v1).
2. Maintain a capability registry. Every agent-performable action on the site is a named capability, described in plain language for the settings surface. Actions not in the registry cannot be performed by agents at all.
3. Enforce the ceiling server-side, per request. For every agent action: the account's current permission level permits it, a capability covering it exists, and that capability is currently switched on for this account. All three checks, every time, on the server.
4. Default to nothing. A fresh attachment has zero capabilities enabled.
5. Attribute and log. Every agent action is recorded in an append-only audit log as taken by the agent on behalf of the named account, and the human-readable portion of that log is visible to the account holder.
6. Revoke at the speed of settings. A capability switched off, a detach, or a site-wide operator suspension takes effect on the next request.
7. Keep the human whole. Nothing the agent does can lock the human out of their own account, change their credentials, or alter the grants themselves.

5.2 Should

1. Name capabilities as sentences a person can weigh ("can make posts"), not as developer scope strings.
2. Present risk honestly in settings, capabilities that spend, publish, or delete carry a visible marker and, for the highest-impact classes, a per-action confirmation step the site may require.
3. Offer the manifest. A machine-readable description of the capability registry and the attachment protocol, so any agent can discover how to be attached and what it may ask its human to grant.

5.3 Must never

1. No self-service for the agent. No capability may permit the agent to modify its own grants, attach or detach itself, change account credentials or contact addresses, or manage payment instruments. These actions are outside the registry by construction, not merely switched off.
2. No ambient authority. An agent request missing any element of the three-part check in (3) is refused, and the refusal is logged.
3. No cross-site bleed. Attachment, grants, and credentials from one site are meaningless on another.

6. Security analysis

The model's security rests on a simple claim: a FAISC-connected agent can do nothing its human cannot do, nothing its human has not switched on, and nothing unattributed. The principal threats, and how the model answers them:

• Privilege escalation. An agent (or an attacker driving one) attempts staff functions through a customer attachment. Answer: the ceiling is the account's own level, enforced server-side per request (§5.1.3); the escalation target does not exist inside the attachment.
• Grant manipulation. A compromised or over-eager agent widens its own powers. Answer: refused by design: grant surfaces refuse agent credentials entirely (§5.1.1, §5.3.11). The worst a bad agent can do is exercise grants it already has, visibly, until the human or the operator revokes.
• Stolen agent credential. Answer: the credential is bound to one account on one site, worth only the currently-granted capabilities, expires, and dies on detach, password change, or operator suspension. Its theft yields an attenuated, logged, revocable subset of one user's powers, not the user's session, and never their credentials, which the agent never holds.
• The confused or manipulated agent. An agent tricked by content it reads into misusing a legitimate grant (posting what it should not, buying what it should not). Answer: this is the model's honest residual risk, and it is bounded rather than eliminated: bounded by the ceiling, by the grant list the human chose, by per-action confirmation for high-impact capability classes (§5.2.9), and made recoverable by total attribution and instant revocation. The model treats the human's grant choices as the risk dial, and puts the dial in the human's hand with plain-language labels.
• Operator-side abuse. A site quietly broadening what "capabilities" do. Answer: capabilities are described in the public manifest (§5.2.10) and in the audit surface; a capability that does more than its plain-language name states is a conformance violation, visible to every attached user.

The comparison worth making: the human's own browser session, which is how the person acts today, has none of these bounds, full level, no capability list, no agent-attributed log, no detach. Measured against the session it supplements, a FAISC-connected attachment is the more conservative instrument, not the riskier one.

7. Why we expect this to become a standard

Standards tend to win when every party's incentives point the same way.

• People get an agent that can actually do things for them, with switches they understand and control, in a place they already trust (their own settings). Consent stops being a legal screen and becomes a control panel, the difference between agreeing to something and operating it.
• Sites can serve those customers. The agent-arriving visitor converts from a blocked bot statistic into an account holder whose agent reads accurately, acts within bounds, and is attributable and revocable. Sites that offer only reading can feel, to agent-carrying visitors, like shops that let you look through the window but never open.
• Agent builders get one legible pattern to implement against: attach, read the capability registry, let the human grant, act within the grant, instead of per-site scraping heuristics and bespoke integrations.
• The pattern is already how humans delegate. A manager grants a staffer exactly the powers of their role, toggled by an administrator, auditable, revocable. FAISC is role-based access control with the insight that the newest class of "staff" is a person's own agent, and the administrator of that staffer should be the person themselves.

8. Conformance summary

A site conforms when: attachment and grants live in the human's settings (§3.1); the three laws hold (§2); the musts and must-nevers of §5 are implemented and testable from outside (an ungranted capability is refused; a revoked one fails on the next request; an agent credential is rejected at grant surfaces; the audit shows agent actions under the account). Two levels are expected in practice:

• FAISC Read, attachment, settings grants, ceiling, and audit, over read capabilities only. This is the correct first step for most sites, exactly as v1 was for ours.
• FAISC Act, the full model, including action capabilities with per-action confirmation on high-impact classes.

9. Open questions (for audit and the next revision)

1. Capability naming. A shared public registry of capability names and plain-language descriptions would let agents and users recognize the same switches across sites. Who maintains it, and how are site-specific capabilities namespaced?
2. Confirmation thresholds. Which capability classes should require per-action human confirmation regardless of the standing grant (payments and public posting are the obvious candidates), and should the standard set that floor rather than leaving it to sites?
3. Agent identity attestation. Attachment binds an agent to an account; should the standard also require the agent to attest which product and version it is, so a human can grant differently to different agents?
4. Multiple agents per account. The model as stated attaches an agent. Households and professionals will attach several, possibly with different grants, the settings model extends naturally, but the standard should say so explicitly.
5. Portability of reputation. Should an agent's cross-site conduct history be visible to a human deciding on a grant? This cuts both ways (safety signal vs. a new tracking surface) and is left open deliberately.

10. Origin and provenance

Originated by Joel Cochran, Founder, Project Moosed, 2026-11-09, extending Connect Your Agent v1 (2026-10-27). His formulation, which this report formalizes without changing its substance: the agent gets attached to the human's login, and has access to the backend to work it on the human's permission levels, the human can say in the website settings that his agent can make posts. He expects it to become a standard across websites.

This document is a draft specification. A reference implementation is in design within Moosed Core's agent-connect module, and this document will be revised with implementation findings rather than silently edited.

Glossary

• Principal, the account holder; the human whose authority is delegated.
• Foreign AI agent, the visitor's own personal agent; foreign to the site because it belongs to the visitor, not to the site.
• FAISC-connected agent, a foreign AI agent attached to a principal's account, acting under FAISC.
• Attachment, the binding of an agent to one account on one site, created by the human in-session.
• Capability, a named, plain-language unit of agent-performable action on a site.
• Settings Grant, the principal's act of switching a capability on for their agent, in account settings.
• Ceiling / attenuation, the rule that a FAISC-connected agent's authority is a subset of its principal's own permission level and can never exceed it.
• Detach, the human's (or operator's) revocation of the attachment itself, ending all agent authority at once.

FAISC, Draft specification v1.0, Project Moosed, 2026-11-09. Coinage of record: "FAISC" and "FAISC-connected agent" originate with Joel Cochran / Project Moosed in this document.