Your account¶

Your account lives in a directory service, a dedicated identity provider the registry signs you in through. Passwords, sign-up, recovery and multi-factor live there; the registry keeps no password of its own. It keeps what it must own: your sessions, your tokens, and every authorization decision.

Creating an account¶

Sign in → "Need an account? Sign up." The form asks for a username (letters, digits and hyphens, in any case — it becomes your registry handle, in lower case, so ChrisY is the handle chrisy; an account created by a first social or SSO sign-in gets its handle from the part of its email address before the @, made unique), a display name, an email address, and a password (12 characters minimum, checked for strength, not just shape). The display name is optional: fill it in if you want your registry name to be different from your username, and leave it blank to use the username as you typed it. A username that differs from an existing one only in case is taken. If you typed a name or an address on the sign-in page before choosing "Sign up.", the form starts with it filled in. The last field, Promo code, is optional too: see Promo codes. Sign-up is guarded by a CAPTCHA and a rate limit counted per client address.

The next screen is the Terms of Service. They sit in a scrolling box, and the I have read and agree box (and Continue) stays unavailable until you have scrolled to the end of them. Tick it to continue; without the agreement no account is created. Your account records which version of the terms you agreed to, and when.

One stage is left after that. Sign-up enrols an authenticator app before it hands you a session, so no account leaves the flow without a second factor. Then you are signed in and on your dashboard: there is no mail to wait for first.

Activating your account¶

A new account is not activated until you follow the link Agentry mails to the address you gave. The registry links identities to accounts by verified email, so until you have shown the address is yours the account can look but not act: you can sign in, read every page, search, and look at QuickAgents, but you cannot publish, create a QuickAgent, install, run, star, mint a token or add an SSH key, buy anything, or create an organization. What stays open is looking after the account itself: signing in and out, your display name and cookie choice, ending sessions, removing remembered browsers, authenticators, tokens and keys, signing the desktop app or the CLI in, accepting an invitation, and deleting the account. A refused action says so and points you at your dashboard.

The mail is sent when you first sign in. It names the account it activates; if you did not create an account with that name, do not follow the link. The link works once, for 24 hours, on any device. It opens a page with an Activate my account button, and the account is activated when you press it, not when the page opens, so a mail scanner that only opens links cannot activate an account for you.

Until then, the first thing on your dashboard is Activate your account, naming the address the link went to, with a Resend activation email button. One mail can be sent every five minutes (the first one counts), and no more than ten in a day; while the button waits it says when it can send again. An earlier link keeps working after a resend until it expires. The banner goes away once the account is activated. The Have a promo code? card waits for the activation too.

If someone signs in with Google or GitHub using the address of an account that was never activated, and the provider has verified that address, the unactivated account is removed and the sign-in creates a new one: the provider has proved the address, and the old account never did. If the provider has not verified the address, the sign-in is refused and the unactivated account is kept.

Signing up with Google or GitHub¶

The sign-in page also shows a row of provider logos under the username field. Pick one, approve Agentry at the provider, and you come back to a short form that finishes the account:

Username, filled in from the provider (your GitHub login, or the part of your address before the @). Change it if you like; it becomes your registry handle, so it must be letters, digits and hyphens (written in lower case), and not a reserved name.
Display name (optional), filled in from the provider.
The Terms of Service, as on the password sign-up.

There is no password, no CAPTCHA and no authenticator to set up, and you end signed in on the page you started from.

Your address. The account takes the address the provider holds for you, and Agentry trusts it only when the provider says it verified it (Google's verified flag; for GitHub, your primary address and its verified mark). When the provider has not verified it, the form also shows the address, which you can change, and Agentry mails a confirmation link to it: the account cannot sign in until you click it. A provider's sign-up never needs activating afterwards: the address is confirmed by the provider or by that link. An address another account already uses cannot be taken this way.

An account you already have. If the provider's verified address is your existing account's address, signing in with the provider connects it to that account; nothing new is created. If the provider has not verified the address, you are asked for that account's password first (and its authenticator, if it has one). Either way, an account with an authenticator is asked for it on every provider sign-in, so the provider does not become a way around your second factor. Once connected, the provider's logo signs you in to the same account each time. Agentry keeps your provider user id, name and address, and no token from the provider.

No password. An account made through a provider has no password. You can add one under Settings → Authentication ("Add a password"). Until you do, "Forgot username or password?" cannot reset it: after the mail it tells you to sign in with your provider instead, because a mailbox alone must never open an account that has neither a password nor an authenticator.

Signing in and out¶

Sign in goes straight to the directory service and returns you to the page you started from. You see its login form and nothing else of it: there is no directory "app panel" to land on, and the directory's own address sends a browser back to the site. Sign out ends both sessions — the registry's and the directory's — and returns you to the site, so signing out actually signs you out without a second login screen.

"Forgot username or password?" on the sign-in page mails a reset link. The form gives the same answer whether or not the address has an account, so it cannot be used to discover who is registered. A reset proves you control the mailbox; it deliberately does not reactivate an account an operator has deactivated.

Recovery also asks for your authenticator before it writes the new password. If you have lost it, an operator has to clear it for you — by design, a mailbox alone does not reset both factors.

Signing in through your organization¶

When your organization's administrator has connected its own identity provider (SAML or OpenID Connect), type your work address on the sign-in page and continue: an address at one of the domains your organization has verified goes straight to your organization's sign-in, and comes back to the page you started from. Any other address goes on to the password, as before. The organization's sign-in is not a button on the page.

The first time. If you have no account yet, one is made for you, only when your address is at one of your organization's verified domains. You agree to the Terms of Service on the way in, and you join the organization as a pending member until one of its administrators approves you. An address anywhere else is refused with a short notice, and nothing is made.
If you already have an account at that address (one you signed up for with a password, Google or GitHub), your organization's sign-in signs you in to that account rather than making a second one, again only at a verified domain. It is refused when two accounts hold the address, and for an operator's account; sign in the usual way instead.
Your second factor is your organization's. When your organization's sign-in tells the registry you used one, and your organization accepts that kind of evidence, it counts as your second factor here.
Your password. An account your organization's sign-in made has no password here, and "Forgot username or password?" will not give it one: your organization's administrator manages how you sign in.

Your dashboard¶

Signed in, the header's account area has a green button for each place you can go: Dashboard for everyone, Organization if you belong to an organization, and Staff if you are platform staff. Sign out is last. The button for the place you are in is drawn lighter. Review work is in those places: an organization's review queue is its console's Reviews, and the platform's is Staff's. A link to /review, like the one in a review mail, still lands on the right queue or version.

Each of those places has a left nav under the wordmark. The Dashboard's covers your dashboard, your runs and your settings, an organization's covers its console, and Staff's covers the staff sections. Browsing, a QuickAgent's pages and the Builder have no left nav. On a phone the nav becomes a strip under the header that scrolls sideways. The Dashboard's nav lists:

Dashboard, the way back to the dashboard itself.
Installed QuickAgents lists the releases you installed to your account, with Update and Remove (see Installed to your account).
Knowledge, where the registry keeps knowledge packs, lists the packs you keep in Agentry and the storage they use (see Knowledge in Agentry).
Voice, where the registry keeps Writing Voices, shows your Writing Voice, the instructions a run follows to write the way you do, with its editor and the Voice Writer (see Writing Voice).
Runs lists your hosted runs, newest first; a run's page has its log, its outputs and Re-run (see Hosted runs).
Publisher holds what you publish, in two parts. QuickAgents lists every QuickAgent in your own namespace, public and private, searched and filtered like Browse, each with its recent activity, Edit (editing a QuickAgent), Settings, and Make private or Make public, Retire or Restore, and Delete (see Managing your QuickAgents). A private QuickAgent is listed nowhere else, and the Builder submits public, after asking you (the Builder). Earnings, where the registry runs it, is Publisher Earnings. While you are in Publisher, the nav lists the two parts under it.
Settings opens on six cards, each leading to its section: Profile (your details, notifications, your subscription — tier, balance and reset date — your Writing Voice's switch, and deleting or clearing the account), Authentication (password, two-factor authentication, personal access tokens and SSH keys), Encrypted storage (your secrets for hosted runs and, where the registry keeps knowledge, the knowledge storage you use), Activity (what the account did lately, and its sessions), Report design (how the PDFs your runs export look) and Dashboard (the optional cards your Dashboard can show, such as Deliverables). While you are in Settings, the nav lists the six sections under it as well. Each card also links straight to what it holds, and a section's Settings heading leads back to the cards.

The Organization button opens your organization's console, and its nav lists the organization's landing and the sections your role there can use: Members, QuickAgents and Knowledge (where the registry keeps knowledge packs) for every member, Reviews for a security reviewer and an admin, and Organization, Notifications and Security for an admin.

The Staff button opens a landing of cards for platform staff, one for each staff section: Reviews (the platform review queue), Trust & safety (abuse reports, and quarantining, blocking or reinstating a QuickAgent), Rulesets, Audit (every organization's audit events; reading them is itself audited), Red team, Sandbox hosts where the registry runs hosted runs, and Accounts, Promo codes and Earnings where it sells subscriptions. Promo codes is where staff make the codes people will enter at sign-up, each with the credits one redemption grants, how many people may redeem it and an optional last day, and disable one. A code is never edited or deleted. Earnings runs Publisher Earnings: the program's state and its payouts, the publishers who earned in a half-month with the share their top payer brought, and, for one publisher, what each QuickAgent and each payer earned it. There staff withhold and release a publisher's earnings, forfeit them or reverse a payout, each with a reason the publisher reads. Welcome tour, where the registry offers one, is where staff write the tour below (see The Welcome tour). The last card, Agentry organization, opens the staff organization's own console, whose sections the nav lists beneath it while you are there.

The dashboard opens with the account you are signed in as and, where the registry sells subscriptions, your tier and balance. New QuickAgent opens the Builder. Then comes anything that needs you now: a submission you cannot pay for yet, a dependency alert on one of your published versions, or the run you have in flight, as one line with a link to it. Where the registry sells subscriptions, a chart of the credits used on each of the last seven days follows, across the page.

Below the chart is a card for each part of the dashboard, each with one line on where it stands: Installed QuickAgents (how many, and how many have an update), Knowledge where the registry keeps knowledge packs (your packs, the storage they use and any your organization shares), Runs (how your last run went), Publisher (how many QuickAgents, and how many are private or retired), then the same four Settings cards the Settings page shows. A click anywhere on a card opens it. Your organization's console, with its QuickAgents and its review queue, is the header's Organization button.

A card whose line the registry could not read keeps the card and leaves out the line, and a list the registry could not read (your QuickAgents in Publisher, the alerts, your runs, a QuickAgent's activity) says so. That is never the same as the list being empty.

The Welcome tour¶

Where the registry offers one, the dashboard shows you a short tour of Agentry the first time you open it: a few pages over the credits chart, with the rest of the page dimmed. Next and Back move between the pages, and the dots in the corner show how far along you are. Skip, or Done on the last page, closes it, and so does Esc. Either way it stays closed: the registry remembers that you have seen it, in every browser. Links in the tour open in a new tab, so the tour is still there when you come back.

Platform staff write the tour. When they publish a new one for everyone, it opens once more on your next visit to the dashboard. While your account is waiting for activation, or is suspended, the tour waits too, and opens on your first visit after that.

To see it again at any time, use Take the tour again at the foot of the Settings page. Seeing it that way changes nothing. The tour works without JavaScript too: its buttons are then ordinary links and forms.

Staff write it in Staff › Welcome tour. The tour is a draft of one to ten pages, each a title of up to 80 characters and its text in the same editor as the Writing Voice, up to 4,096 bytes. Links in it must be full https: or mailto: addresses; any other link shows as its text. Each page has its own Save. Up, Down and Remove change the order and the number of pages, and Add page adds one at the end. The draft is nobody else's to see: Preview on your Dashboard opens it there as people will see it, and records nothing.

Two buttons make the saved draft live. Publish is quiet: anyone who already finished or skipped the tour is not shown it again, so it suits a fix. Publish and show to everyone asks you to type CONFIRM, and then everyone sees the tour once more on their next visit to the dashboard. The very first publish is shown to everyone, whichever button you press. Both publish the draft as last saved, so save each page you changed first: the browser asks before you leave the page with a change not saved. If someone else saved the draft after you opened the page, your change is not saved and the page says so. It then shows their version, for you to make your change again.

Every publish is kept. Versions lists each with when, by whom, and whether it was shown to everyone, and Restore into the draft copies a version's pages back into the draft without publishing anything. Who finished it counts, for each version shown to everyone, how many people closed the tour, how many finished it, how many skipped it, and on which page they skipped. It never says who.

Password and two-factor authentication¶

Your password and authenticators are kept by the directory service, but you manage them from Settings → Authentication on the registry. The buttons there are Change password, Add authenticator app and Add security key / passkey, with a Remove beside each entry under Enrolled authenticators. Each one opens a single step in the directory service and brings you straight back to Settings.

The registry keeps no second factor of its own, so its gate on publishing to a public namespace is off unless the operator turns it on. It is then satisfied by evidence rather than by an enrolment here: the registry records that your sign-in carried a second factor.

Subscription tiers and credits¶

Every account on the hosted registry has a subscription tier. Two are for a person — Standard (free) and Pro — and two are for an organization — Business and Enterprise — where membership is the tier: a member of a paid organization has everything Pro gives. A tier grants credits each month, and every submission to the review pipeline spends some. Standard grants 50 a month; a submission costs 1, so up to fifty. Pro grants 1,000. Standard holds up to ten private QuickAgents in your own namespace; Pro has no cap. Business and Enterprise bring credits per seat into one shared pool for the organization — the amounts are on the pricing page. A hosted run and, on Pro, Business and Enterprise, a knowledge build in Agentry spend credits too: each holds credits for its caps and settles at what it used, never more than it holds, and each is stated in credits only (Hosted runs). The Voice Writer in Agentry costs 20 credits flat a run, once a billing cycle on Standard, and AI Review of a voice you save by hand 1 (Writing Voice). The pipeline is the same on every tier: no tier changes what the scanners look for, or what the gate decides for any public QuickAgent.

Credits are spent when the registry accepts a submission, after every check that could reject the package, so a broken manifest costs nothing. A version the gate sends to review costs the same as one it publishes; a submission the pipeline itself fails — a scanner that could not run — is refunded. When the balance cannot cover a submission the registry answers 402 credits-exhausted, naming the balance and the reset date, and, for a member of an organization, whose balance is short — the organization's pool; the CLI, the Builder and the desktop app show that sentence.

The allowance resets on the day of the month the account was created, and unused credits expire with it. Your balance, the reset date and the upgrade to Pro are on Settings › Profile, under Subscription; an organization's seats, pool and standing are on its admin console, in the Organization section's Subscription. A downgrade or cancellation takes effect when the current cycle ends.

Your dashboard shows the credits used on each of the last seven days. A member of an organization sees the organization's pool, which is what they spend from.

Each tier also carries a knowledge allocation: the storage for the knowledge packs you keep in Agentry. Standard has 100 MB and Pro 5 GB; Business and Enterprise pool 10 GB a seat, shared by the organization's packs and every member's. Only packs kept in Agentry count; packs kept on your computer by the desktop app or the CLI do not. A cap never deletes anything. After a downgrade, or when an organization's pool shrinks, every pack stays readable and can be exported, but a new pack, or a larger copy of one, is refused with 413 knowledge-allocation until enough is deleted or the allocation grows. Settings › Encrypted storage, Settings › Profile (under Subscription) and the Knowledge page show what is used of it.

A promo code puts a new account on Promo Pro for 30 days: everything Pro gives, paid for with the credits the code carries instead of a monthly allowance. No payment is taken, and none is asked for at the end.

There are three ways to use one:

On the sign-up form. Type it in the Promo code field. It is applied when you activate your account from the emailed link.
From a promo link. A link of the form https://secureagentry.net/signup?promo=CODE opens the sign-up form with the code already filled in.
On your dashboard. For the first seven days of an account, the dashboard has a Have a promo code? card. Use it if you left the field empty, signed up with a social account, or the code you typed was refused. The card says why a code was refused: not a valid code, used as many times as it allows, or past its last day.

An account can redeem one promo code, ever, and only while it is a person's own Standard account that has never had Pro and is not a member of an organization. Nothing checks a code before the account exists, so the first page you see after sign-up (your dashboard) is where you learn what it gave you.

During the trial the dashboard and Settings › Profile show Promo Pro, your promo credits and the day they end. When the 30 days are over:

the promo credits you have not spent expire;
the account moves to Standard and gets Standard's 50 credits that day, with a new monthly cycle starting then;
nothing is charged. The trial never turns into a paid subscription.

Private QuickAgents and knowledge above Standard's caps are kept, as after any move down from Pro: nothing is deleted, but nothing more can be added until you are under the cap. A reminder mail is sent three days before the end.

Buying Pro during the trial ends it at once: the promo credits expire and Pro's 1,000 a month begin. Joining a paid organization also ends it, and the promo credits expire rather than joining the organization's pool.

Credit packs¶

On Pro or Promo Pro, on your own account, you can buy more credits in one payment, without changing your tier. Where the registry sells them, Settings › Profile has a Top up credits card under Subscription with two packs: 1,250 credits (1,000 plus a 250 credit bonus) and 5,000 credits (3,500 plus a 1,500 credit bonus), each at the price the card shows. Payment is taken on the payment provider's own page; Agentry never sees your card. The credits are added when the provider reports the payment, which can take a moment after you come back.

Credits you buy never expire. Your monthly credits (or a promo trial's credits) are spent first, and the bought ones only after them, so a renewal gives you a fresh allowance and leaves what is left of a pack in place. They stay yours after a move down to Standard or the end of a promo trial, and move into an organization's pool with the rest of your balance if you join a paid one. Members of an organization spend from its pool and are not offered packs.

A refund takes back the pack's credits you have not spent. If a payment fails or is disputed after you spent some of the pack, the account is suspended for non-payment: it owes those credits, and submissions, hosted runs, knowledge builds, drafts and hosted sessions are refused until the balance is back at zero. Sign-in, installs and your published QuickAgents keep working. The next credits to arrive pay what is owed first; while suspended, a pack is paid by card only. Only one pack whose payment is still clearing can be held at a time.

When your balance falls below 100 credits, your dashboard shows a banner once, with a link to the Top up credits card. Dismiss hides it on every device until your balance has been back at 100 or more and falls again.

Earned credits¶

Where the registry runs Publisher Earnings, the publisher of a public QuickAgent earns credits when other people run it in Agentry, paid twice a month as earned credits. Like bought credits they never expire; they are spent after your monthly or promo credits and before the bought ones, and a pack's refund never takes them. Earning from your QuickAgents says what earns, how to join and when you are paid.

Installed to your account¶

Signed in, a published QuickAgent's page offers Install vn beside its other actions. It opens one page that shows the contract you would be accepting — the declared capabilities as the author wrote them, what stands behind the release ("scanned, N findings", or unscanned in its own colour when the registry admitted it without a scan), and whether it is signed — with a box for each acceptance the release needs and one button. Confirming records the release on your account: the version, and the contract as you accepted it. Nothing is written on any machine. The desktop app and the agentry CLI keep their own, per-machine record of what they laid down, and the two are never synced; installing here does not install there, and the reverse.

Installed QuickAgents, in your dashboard's left nav, lists what your account holds: the QuickAgent, the version you accepted, whether a newer version is published ("update available"), the capabilities you accepted in one line, what stands behind the version, and when you installed it. From a row: Open its page, Update when something newer is published — the same page, showing what changed against the contract you accepted, and asking again only for what changed — and Remove, after a confirmation. The page's button reads Installed afterwards, or Update to vn.

A QuickAgent you can no longer read — made private, or its organization suspended — stays on the list as the name you installed it under, marked no longer available, with Remove alone. Installing to your account moves no download counter and is not a star: a star is public approval; this is your own record of a contract you accepted.

Knowledge in Agentry¶

Knowledge, in your dashboard's left nav, lists the knowledge packs you keep in Agentry, with the storage they use against your allocation (above). Making packs, keeping and exporting them, an organization's shared packs, attaching packs to a run and shipping one with a QuickAgent are on their own page: Knowledge.

Notifications¶

Settings → Profile carries a Notifications card that decides how the registry's alerts reach you. Email goes only to a verified address: until you have activated the account, no notification mail is sent whatever the switches say. Email, per kind: a published version of yours declares an MCP server with a newly known vulnerability; a rescan quarantines a published version of yours; a reviewer decides one of your submissions; the registry publishes an advisory naming one of your QuickAgents; you are added to an organization. In the web app: whether the dependency-alert banner shows on every page while one of your versions has an open alert.

Everything is on until you change it. Your dashboard lists open alerts whichever way the banner is set, and these switches do not change an organization's webhooks or its audit trail. One more switch, staff mark a bug I reported fixed, decides whether you get the email that a bug you reported is fixed.

Reporting a bug¶

Something on the site not working as it should? Report bug, at the foot of every page under Contact, opens a page with a text box. Say what went wrong and what you were doing, in 10 to 4,000 characters of plain text, and press Submit; Cancel takes you back to the page you were on. You need to be signed in, and an account you have not activated cannot send one. You can send up to ten reports an hour.

The report records your account and the page you came from, and nothing else. Agentry staff read it under your handle, never your email address. When they have fixed the bug, they mark the report complete and you get an email, Reported bug fixed, that quotes your report and its date and may carry a note from them. A report they close as a duplicate or not a bug gets no email. The email goes only to a verified address, and only while the switch above is on. Deleting your account deletes your reports.

Report design¶

Settings → Report design sets how the PDFs your runs export look. A QuickAgent makes a PDF when you ask for one, or when its report is meant for someone else. It chooses only the document's form, a report, a letter or a memo; it never chooses the look, and asking it for a formal tone changes its words, not your design.

The page opens on five themes, each a starting point with a look of its own: Plain (near-monochrome, the default), Classic (serif, navy small-capital headings), Modern (a blue title band, banded tables), Editorial (a display face for headings, warm red rules) and Technical (numbered teal headings, banded tables). Their pictures are drawn by the runner's own template from one sample report, so they show what a run draws. Choosing one loads it into the editor, where you can change:

the name, which a run's receipt records;
the paper, A4 or US Letter;
the fonts for headings, body text and code, from fourteen open-licence families (a script a face lacks, Chinese or Arabic say, is set in Noto);
the accent, the one colour of the design, and its tint behind table headers and callouts;
the title block (a band, a bar, rules, or none), the headings (a rule, a bar, small capitals, numbered, or plain), the tables (a tinted header row, alternate rows tinted), the quotes (a callout or plain);
the footer: page numbers ("1" or "1 of 3", or none) and one line of your own text.

A preview beside the controls follows every change. It is drawn by your browser, so it is a likeness; the theme pictures are the real thing. Body text stays near-black whatever you choose, and an accent that would be hard to read is refused: one that colours text (a band title, small-capital or numbered headings) must reach 4.5:1 against the white page, and one that colours only rules and bars 3:1. The page then names the nearest shade of your colour that does, and Use puts it in. Save stores the design on your account; Reset forgets it.

Once a design is saved, Logo adds yours: a PNG or a JPEG of at most 512 KB. The registry decodes it, scales it down to fit 1024 pixels each way and encodes it again from its pixels, so nothing of the file but its picture is kept; SVG is not accepted. Each PDF your runs export draws it at the right of the title on its first page (on a small white ground in a band, and alone at the top right when the document has no title) and nowhere else, and the preview shows it there. The QuickAgent never chooses it. Saving the design keeps the logo, Remove the logo takes it off and keeps the design, and Reset forgets both. Runs from the command line draw it from version 0.6.91.

Having no design is not the same as Plain. Runs then use Plain, except a run from the agentry command line, which uses the design or theme in its own config when that names one. Runs from the command line, version 0.6.88 or later, use your whole design, and its --report-design FILE and --report-theme NAME flags choose one for a single run (the runner). The desktop app uses your whole design from version 0.6.84 and draws your logo from 0.6.86. Runs on Agentry's hosts use your whole design and your logo too; a host whose runner predates that draws only the theme your design started from, without your changes, and an even older one Plain.

No design carries Agentry's name or logo, only yours, and a PDF names the QuickAgent that made it, never you. Clearing the account's data clears the design too.

Sessions¶

Settings → Activity holds two cards. Recent activity lists what the account did lately — sign-ins, tokens and keys created or revoked, profile changes, publishes, reviews — each with the address and client it came from, so an action you do not recognise stands out. Sessions lists every browser session on the account with its start time, last activity, address and user agent.

Revoke one, or Sign out everywhere else to end all but the current one. Revoking a session invalidates its cookie immediately. It does not revoke personal access tokens: those live under Settings → Authentication, and you revoke them there.

Personal access tokens¶

The CLI and other API clients authenticate with personal access tokens, managed under Settings → Authentication. Tokens are scoped — repo:read, repo:write, agent:publish, agent:read, agent:manage for the owner actions on your own QuickAgents (make public or private, retire, restore, delete), which the desktop's sign-in also carries, org:admin, review:act, audit:read, user:profile, run:read and run:write for hosted runs, knowledge:read and knowledge:write for the knowledge packs you keep in Agentry, voice:read and voice:write for your Writing Voice — and revocable individually; treat them like the credentials they are.

Neither the desktop app nor the CLI asks you to paste one. agentry login (on a terminal) and the desktop's "Sign in via browser" open your browser, you sign in as usual, and one explicit approval page hands the app a one-time code, valid for 60 seconds, on a local listener. The app exchanges that code for a scoped token from its own process, so the token itself never appears in your browser. agentry login --paste still accepts a token from Settings → Authentication for machines without a browser, and revoking either kind later is the same list.

A script or CI job can hand the CLI a token in the environment instead of signing in. For Agentry, set SECUREAGENTRY_TOKEN:

export SECUREAGENTRY_TOKEN=agy_…   # a token from Settings → Authentication
agentry whoami

The CLI you download from Agentry sends SECUREAGENTRY_TOKEN to this site and to nowhere else: a command pointed at another registry does not send it, and says so. AGENTRY_TOKEN is the variable for a self-hosted Agentry registry and is never sent here. If a script of yours sets AGENTRY_TOKEN for this site, switch it to SECUREAGENTRY_TOKEN: the CLI refuses AGENTRY_TOKEN unless a self-hosted registry is configured. Running your own registry is covered in self-hosting.

SSH keys¶

Settings → Authentication → SSH keys registers public keys for git clone ssh://git@…/ns/name.git and pushes over SSH, on instances that serve the SSH transport. A key is worth repository read/write and the release tag your role allows — never the API — and organizations that enforce SSO take pushes only over HTTPS with an org-bound token.

On SecureAgentry, adding a key is part of Pro, Business and Enterprise, and of a Promo Pro trial; a member of an organization may add one whatever the organization's standing. On Standard the add form is replaced by that sentence, and the registry refuses an add with 403 feature-not-included. Clone and push over HTTPS with a personal access token instead. A key you already hold keeps working on every tier and can be removed, including after Pro or a promo trial ends.

Organizations¶

An organization is a paid Business or Enterprise subscription that a team shares. There is no free organization: you create one by starting a Business or Enterprise plan from the pricing page or at /orgs/new, which sets up the organization and takes its seats to the payment provider. You belong to one organization at a time.

Roles. A member is an admin, a security reviewer, or a plain member. The organization's console opens on a card for each section your role can use. Every member sees Members (who belongs, their seats, and teams), QuickAgents (the organization's namespace, private ones first and marked, with Publish and Settings) and Knowledge (the organization's shared packs, where the registry keeps knowledge). A security reviewer also sees Reviews, the organization's review queue, where a version the gate holds is opened and decided. An admin sees every card, and with them Organization (the subscription, Publisher Earnings, publication policy, the logo, verified domains, and decommissioning), Notifications (webhooks and alert routing) and Security (single sign-on, SCIM provisioning and the audit log), and also manages invitations, the people waiting for approval and the shared packs. A card you do not see is not yours to use: its page still answers for itself, and refuses you. Every member publishes to and installs from the organization's namespace as their grants allow. The review mail's link to a version, and the old review queue's address, still land on the console's Reviews.

Seats. The subscription is billed per seat each month, and every member holds one. Each seat brings a monthly credit allowance into one shared pool the whole organization draws on. Business holds at most 25 seats; Enterprise has no cap. An admin changes the seat count from the console's Organization section; the payment provider bills the change.

Joining. An admin invites a person by handle or email; the person accepts to take a seat. Someone whose verified email is at the organization's domain is folded in on their next sign-in as a pending member and works on their own tier until an admin approves them — the seat check runs at approval. An admin can also approve or decline the people waiting, from the console's Members section.

Single sign-on. An organization can configure SAML or OIDC single sign-on and SCIM provisioning from its console's Security section; a connection can be tested before it is enforced, and SSO is supported but never required. Signing in through the directory service as an individual never grants organization membership by itself.

Restricted mode. If the subscription lapses or a payment fails, the organization enters a restricted mode: no credits accrue and new submissions, hosted runs and added seats are refused, but its people still sign in, read every QuickAgent, change settings and export — nothing is removed or locked out. The console shows the standing and the way to resolve it.

Decommission. An organization can be decommissioned. After a notice period its QuickAgents, repositories and invitations are removed and its handle and any verified domain are released; trust-and-safety records outlive it. Reads and the audit export go on until the hold ends, and a member may still leave.

Unscanned private agents. On a plan that includes it, an admin may take one of the organization's private QuickAgents off the review pipeline from its settings, behind a page that spells out what is given up. A version published that way is admitted without a scan: it carries no findings, no report and no signature, is labelled unscanned wherever it is shown, and agentry install and agentry run (and the desktop) ask for consent — --allow-unscanned — before using it. This reaches only that organization's own private QuickAgents; a public QuickAgent is always scanned, and one cannot be made public while an unscanned version of it stands published, quarantined or blocked.

Deleting your account¶

Account erasure is an API call, POST /api/v1/user/delete, described under API conventions: it purges personal data, revokes every credential, asks you to choose what happens to any published versions (they are yanked or transferred, never deleted), and — where the operator has configured it — removes the sign-in account from the directory service as well.