Sharing & Access

Every site has an access setting that says who can open it. It is shown on the site's page in the portal, in the Access card, and in the Access column of the sites list.

The four access values

Each value names a set of people, from the narrowest to the widest:

To let someone outside Axelerant in, either:

• invite them by email, the default way to share with named people, on a site whose access is Axelerant and invited people or Only invited people (or Anyone with the link). Each person signs in as themselves, and you can remove one person without affecting anyone else; or
• send them the share link, a URL with a token in it, on a site whose access is Anyone with the link. It is the fallback for when you cannot name everyone.

Both work side by side on a site shared by link, and Axelerant colleagues keep signing in with Google as always, except on a site set to Only invited people, where they have to be on the list like everyone else.

Everyone at Axelerant (default)

An internal site is accessible only to people with an @axelerant.com Google account. When someone visits the site, they're prompted to sign in with Google SSO if they don't already have a session.

No setup is needed — this is the default for all new sites.

How to share internally: send the URL. That's it.

https://axelerant-context.stele.axelerant.tech

The recipient signs in with their Axelerant Google account and sees the site. Axelerant colleagues never need an invite or a share link.

Changing a site's access

On the site's page in the portal, the Access card shows the current value and the four choices. Press one to change it. Choosing Anyone with the link on a site that has never had a share link creates one. An agent connected to Stele's MCP server can do the same with set_access, or with rotate_share_token, which also creates a share link if the site has never had one.

Who may do this: the person who added the site, and anyone whose Stele role lets them manage every site.

Only invited people

Choose Only invited people for a site that only named people should open, whether they work at Axelerant or not: a client deliverable that colleagues on other accounts should not see, say. Put each person on the viewer list, colleagues included; colleagues who can see the repository on GitHub are on it already. A colleague who is not on the list sees a No access page rather than the sign-in page, since signing in again would not help. Setting this on a site whose viewer list is empty, with nobody invited and nobody there from GitHub, locks everyone out, you included, until someone is invited.

Axelerant and invited people

Choose Axelerant and invited people to open a site to every colleague and to the named outside people on its viewer list, with no share link. It is the value to use for a client site.

Choosing any value other than Anyone with the link switches the site's share link off; the token is kept, so choosing Anyone with the link again brings the same link back. To make sure an old link never works again, rotate it first.

How access settings combine

More than one setting can say who may see a page: the site's access, an access: in a folder's .stele.yml, the archived-repository rule, and for the assistant the corpus audience. Each names one of the four sets of people above, and a page is open to someone only if every setting that applies to it admits them. Settings intersect; none of them can widen another.

Three things follow:

• A folder is never more open than its parent, or than the site. access: link inside a folder marked Only invited people is still only invited people. Nothing in a repository can open a site wider than the portal set it.
• Two settings that do not contain each other give you the people in both. A site set to Only invited people with an Everyone at Axelerant folder shows that folder to the listed people who are Axelerant staff, and to nobody else.
• Archiving a repository on GitHub intersects the site with Everyone at Axelerant. Outsiders are shut out whatever the setting; an Only invited people site then admits only its listed staff.

Anyone a folder does not admit is sent to sign in, or, when they are already signed in with Google, told they have no access. A guessed path under such a folder is refused whether or not the page exists, so the refusal reveals nothing, and the file browser leaves out what the viewer cannot open. The assistant follows the same rule: it never answers from pages the asker cannot open.

Invited viewers

Each site has a viewer list: the email addresses invited to it. A person on the list can open the site once they have signed in, with no token.

The list lets people into a site whose access is Only invited people, Axelerant and invited people or Anyone with the link. On an internal site it is kept, but it admits nobody: an internal site stays Axelerant-only.

Colleagues with access to the repository

Axelerant colleagues who can see a site's repository on GitHub are on its viewer list without being invited, marked From GitHub. That covers every way GitHub grants access: directly on the repository, through a team, or as an organization owner. Any level counts, from read to admin; it lets them view the site and nothing more. So an Only invited people site on a presales repository opens to the people working on the deal, and you invite only the client's contacts.

Stele checks GitHub every hour and after each sync of the site. Someone given access on GitHub appears within the hour; someone whose access is taken away on GitHub drops off at the next check. Stele recognises a colleague by the Axelerant email address their GitHub account has verified, so someone whose GitHub account has no verified Axelerant address is not found, and has to be invited like anyone else.

A few consequences:

• You cannot remove a GitHub entry in Stele. Stele would only add it back at the next check. Take away their access to the repository on GitHub instead.
• Inviting a colleague who is already there from GitHub turns their entry into an invite. It then stays when their GitHub access ends, until someone removes it.
• An internal repository is readable by everyone in the organization, and a public one by everyone, so on such a repository every colleague appears on the list, and Only invited people admits them all. The Viewers card says so on such a site.

Adding and removing people

The site's page in the portal has a Viewers card on its Overview tab, under the Access card. It lists everyone invited, with who invited them and when, and the colleagues who are there from GitHub.

To invite: type the addresses into Invite by email and press Invite. Several go in at once, separated by commas or spaces, and a recipient list pasted from a mail client (Ana Lopez <ana@client.io>, Raj <raj@client.io>) works as it is. One address that is not an email address stops the whole invite, so nothing goes in by halves. Inviting someone who is already on the list does nothing, and the card says so.

To remove: press Remove beside the address and confirm. An entry from GitHub has no Remove: take the person's access away on GitHub. It takes effect on that person's next page load (see Removing someone).

Above the field, the card says when an invite would admit nobody as things stand: when the site's access is Everyone at Axelerant (the list is kept but closed), when Stele cannot send email (see below), and when the repository is archived on GitHub.

An agent connected to Stele's MCP server can do the same, and can invite people while it onboards a repository:

• "Invite ana@client.io and raj@client.io to the Acme proposal site."
• "Who's on the viewer list for presales-2026-acme?"
• "Take raj@client.io off the Acme site."

Who may change the list: the person who added the site, and anyone whose Stele role lets them manage every site. Anyone who can see the site in the portal can read the list.

Telling the person

Inviting someone sends them nothing by itself. Either send them the site's plain address yourself, without a token:

https://acme-proposal.stele.axelerant.tech

or tick Email each new person an invitation with a sign-in link to the site before you press Invite (with an agent, ask for the people to be notified). Each newly added person then gets an email from Stele saying that you have invited them to view the site, with a View button that signs them in and brings them to the site. The button is a sign-in link like the one described below: it works for 2 hours, and once it has expired the page it opens asks for their address and sends a new one. At most 10 people can be emailed in one invite, and someone already on the list is not emailed again; if they need access again, they open the site's address and enter their email.

The checkbox is greyed out on an installation without an email provider (see below).

How an invited person signs in

When someone opens the site without being signed in, Stele sends them to its sign-in page and brings them back to the page they asked for afterwards.

• An @axelerant.com address signs in with Google, as always.
• Any other address signs in with an emailed link:
  1. On the sign-in page they enter their address under Invited by email? Get a sign-in link and press Email me a link.
  2. Stele answers If that address is invited, a link is on its way. It gives that same answer for every address, invited or not, so the page never reveals who is on a list.
  3. The email holds a link to a confirmation page. Pressing Sign in on that page is what signs them in. Opening the link alone does nothing, so a mail scanner that opens links on its own cannot use it up.

A few rules apply to the link:

• A link works once, for 2 hours after it is sent. If it has expired or has already been used, the page it opens asks for the email address again and sends a new link, which still leads back to the site.
• At most 3 links per address in 15 minutes. Asking more often gets the same answer, but no email.
• One sign-in lasts 7 days and covers every site the address is invited to and may open, not just the one they started from.

If someone arrives with an old or rotated share link, the error page has a Sign in button, so an invited person can still get in.

Invited people can read the sites they are invited to. They cannot use the portal.

Installations without email

The email option appears on the sign-in page only once Stele has an email provider configured (production has one). On an installation without one, the sign-in page goes straight to Google, the viewer list gives nobody outside the organization access, and the option to email invitations is greyed out. The Viewers card says so, and invites made then are kept: they start working, with no further step, once email is set up. Until then, use the share link for people outside the organization.

Removing someone

Take the address off the list. It takes effect on that person's next page load, even if they signed in minutes ago.

Removing an address does not change the share link. If the person also has the share link, rotate it as well.

Invited viewers and Ask

If the site has Ask enabled, an invited viewer can ask questions where the corpus declares audience: invited or audience: all. invited is the one to use for a client: it admits staff and invited viewers but not someone who only has the share link. Invited viewers are known by address, so their conversations in the portal show as ana@client.io (invited).

The share link (fallback)

The share link lets anyone who has it read the whole site, with no sign-in. Use it when you cannot name everyone who should see the site.

Getting the link

Once the site's access is Anyone with the link, the Access card on the site's page shows the link. It looks like:

https://axelerant-context.stele.axelerant.tech?token=<token>

Send this URL to your external recipient. When they open it:

• No login is required
• A session cookie is set so they don't need the token in the URL for subsequent visits (valid for 7 days)
• They have access to the entire site, not just one page

Who can get the link

Anyone who can see the site in the portal can copy its share link from the site's page, or have an agent fetch it through MCP. Changing the link is narrower: changing the site's access and rotating the token are for the person who added the site, and for people whose Stele role lets them manage every site.

Who can still open a site shared by link

Anyone with the link is the widest value, so every way in works on such a site:

• People outside Axelerant — via the share link (no sign-in), or as invited viewers once signed in
• Everyone at Axelerant — via Google sign-in (no token or invite needed)

Opening a site to the link never locks out colleagues. A folder inside it can still be narrower, through access: in its .stele.yml; see How access settings combine.

If the site has Ask enabled, share-link viewers can read every page but cannot ask questions unless the corpus declares audience: all (audience: invited admits invited viewers, not share-link ones). The default keeps the assistant for everyone at Axelerant even on a site shared by link.

Revoking access

One invited person: remove their address from the viewer list. See Removing someone.

Everyone holding the share link: rotate the token.

1. Open the site's page in the portal
2. Press Rotate token in the Access card
3. A new link is generated; the old one stops working immediately

All existing token-bearing URLs stop working instantly. Anyone who had access via the old token loses it. To restore access for specific people, share the new URL with them, or invite them instead. Rotating does not affect invited viewers.

Everyone holding the link, but not the invited people: choose Axelerant and invited people in the Access card. The link stops working and the viewer list keeps working. The token is kept, so choosing Anyone with the link again brings the same link back; rotate it first if that must not happen.

All outside access: press Switch the link off, which removes the share link and sets the site to Everyone at Axelerant. Invited viewers lose access too, because the viewer list admits nobody on an internal site; their addresses stay on the list for when the site is opened again.

Everyone but the named people, colleagues included: choose Only invited people. Check the viewer list first: colleagues who can see the repository on GitHub stay in, and an empty list locks everyone out, you included.

An agent connected to Stele's MCP server can do the same with remove_viewer, rotate_share_token and set_access.

When the work is over: archive the repository on GitHub. Its site then admits only signed-in Axelerant staff: the share link and every invite stop working, whatever the site's access setting. Nothing is deleted, so unarchiving the repository brings back the same link and the same invites. Archiving the site in Stele is different: it stops syncing but keeps the site open to everyone who could see it (see Retiring a site).

Important details

• One token per site. There's a single share token for the entire site — not per-user, per-page, or per-link. Everyone you share it with gets the same token. Invite people by email when you need to tell them apart.
• Whole-site access, unless a folder says otherwise. The share link and an invite both open every page on the site, except pages under a folder whose .stele.yml sets a narrower access:. That is the one way to keep part of a site from some of its viewers; it can only narrow, never widen.
• No expiry for the share link. Tokens don't expire on their own. They remain valid until you rotate them. An invite also stays until you remove it.
• Rotation invalidates immediately. When you rotate, the old token stops working right away. There's no grace period.
• Seven-day sessions. After first use, the token is stored as a browser cookie for 7 days. An email sign-in also lasts 7 days. Removing an invite still takes effect on the next page load.

Common workflows

Share a deliverable with named client contacts

1. Push your deliverable to the repo
2. Set the site's access to Axelerant and invited people in the portal (or Only invited people, if colleagues outside the account team should not see it either; put the team on the list first)
3. Invite each contact's email address in the Viewers card, ticking the notification if Stele should email them the link, or have an agent do it
4. Otherwise send them the site's plain address; they sign in with an emailed link

Share a deliverable with a client you cannot name

1. Push your deliverable to the repo
2. Set the site's access to Anyone with the link in the portal
3. Copy the share link
4. Send it to the client

Remove one person

Press Remove beside their address in the Viewers card, or have an agent do it. If they also had the share link, rotate it and resend it to the people who should keep access.

Revoke a client's access after a project ends

Archive the repository on GitHub. That intersects the site with Everyone at Axelerant, so everyone outside is shut out, and it can be undone. To close it while the repository stays active:

1. Open the site's page in the portal
2. Choose Everyone at Axelerant in the Access card, or press Switch the link off to remove the link as well; rotate the token instead if others should keep the link
3. Remove the client's addresses from the Viewers card if they should not come back when the site is opened again

Give access to a new stakeholder after rotating

After a rotation, the old URL is dead. Copy the new share link from the portal and send it to anyone who should still have access, or invite them by email instead.