What you will learn Authentication versus authorisation, what passwords, tokens and keys each are, why least privilege is the rule, and what to do when a key leaks.
HyperTeamsgraph TD
A["a request arrives"] --> B["authentication<br/>who is this?"]
B -->|"unknown → 401"| X["refused"]
B -->|"identified"| C["authorisation<br/>may they do this?"]
C -->|"no → 403"| X
C -->|"yes"| D["run it"]| Authentication | Authorisation | |
|---|---|---|
| Asks | who are you | what may you do |
| Means | password · key · SSO | roles · permissions |
| On failure | 401 | 403 |
The 401 and 403 from HTTP are exactly these two. No number of fresh keys resolves a 403 — that needs a permission.
| Password | Token · API key | SSO | |
|---|---|---|---|
| Used by | a person | a program | a person |
| How many | one | one per purpose | one company account |
| Expiry | none until changed | can be time-limited | per session |
| If leaked | the whole account | only that key's scope | cut off by company policy |
The bottom two rows are why tokens beat passwords here. Scope and lifetime
can be narrowed, so a leak stays inside that scope. The tt_-prefixed system
tokens in HyperTeams and Connect's API keys both work this way
(Calling it via API key).
Widening happens the moment someone is blocked. Narrowing only gets noticed after someone's work stops. Order matters — Tools are permissions and Members and roles apply the same rule to tools and to people.
It applies to agents identically. An agent acts with the permissions of the account it was given, not its own. Give it a read-only account and it cannot delete anything even if asked.
A password is something you know, so learning it is enough to be you. Adding something you have (an authenticator on a phone) is two-factor authentication (2FA/MFA).
Turn it on for administrator accounts without exception. Most incidents start not with sophisticated attacks but with a password leaked elsewhere being tried here.
Creating a key takes ten seconds; finding everywhere it was planted takes days.
Do not leave keys in a .env and push it to a shared folder or repository.
That is why the hidden files from Files, folders, paths are
dangerous — invisible, and uploaded along with everything else.
| Per-person settings | Roles | |
|---|---|---|
| New joiner | configure each thing | assign a role |
| Leaver | hunt down where they had access | revoke the role |
| Audit | one per person | one per role |
That is the job of Members and roles and Groups and departments, and joining it to the company directory is SSO.
It is about incidents, not people. If one account leaks, everything it can reach leaks, and an accidental deletion reaches exactly as far.
It is. And the moment that code is copied or shared, the key travels with it. Keys in configuration, only names in code.
1. Authentication versus authorisation?
Authentication asks "who are you"; authorisation asks "what may you do". They surface as 401 and 403.
2. Why is "grant broadly now, narrow later" dangerous?
Narrowing gets postponed. Being blocked is reported immediately; excessive permission is noticed only after an incident.
3. What do you do when an API key leaks?
Retire it and issue a new one. You do not repair it — which is why each key needs a name telling you where it was used.
That is IT basics. Now look at AI itself with the same eyes → The four properties of the machine
✗ Grant admin now and narrow it later → "later" never arrives✓ Grant what is needed; widen when something is blocked□ A different password per service — one breach stays one breach□ Length beats complexity — a long phrase outperforms a short cryptic string□ Use a password manager — reuse comes from trying to memorise□ Give it a recognisable name ✓ "intranet-summariser" ✗ "key1" · "test"□ Record where you put it□ Never paste it into code or a chat window□ Rotate it when the owner changes□ If it leaks, delete and re-issue — you retire it, you do not repair it