IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Non-human identities — Bot A's chapter
For every human login, companies now run many logins that belong to software. They never quit and never fall for phishing. But nobody watches them. Your goal: list the controls that keep a bot like Bot A safe.
- A non-human identity (NHI) is a login that belongs to software.
- Give every NHI an owner, a vault, rotation and least privilege.
- Best of all: no stored secret. The platform vouches for the program.
- Remove old bots. Do not leave zombies.
Bot A gets its life in order
A non-human identity (NHI) is any login that belongs to software, not to a person. It needs the same care as an employee. Here is Bot A's clean-up checklist.
| Idea | Bot A's version |
|---|---|
| Registry | A list of every NHI: owner, business sponsor, purpose, allowed systems, risk tier and review date. If it is not on the list, it does not run. |
| Vaulting | Secrets live in a guarded safe (the privileged-access vault), never in scripts or config files. |
| Secret rotation | Credentials change automatically and often. Best of all are short-lived credentials fetched just in time. Then there is nothing lasting to steal. |
| Workload identity federation | The platform itself vouches for the program. Bot A gets tokens without holding any secret. |
| Least privilege + SoD | Refunds up to a limit, in one system, in its nightly window. Nothing else. No bot may request, approve and check the same action. |
| Lifecycle and orphan detection | The sponsor re-confirms every quarter. Old bots are removed automatically. An alarm sounds if the sponsor leaves. No zombie bots (the lifecycle lesson applies to machines too). |
How a program proves who it is
SPIFFE is an open standard. It gives every workload (a running program) a universal name, like spiffe://acme/refunds/bot-a. It also defines a short-lived digital ID called an SVID. SPIRE is the software that hands out SVIDs. First it checks the workload. Is this really the refunds service, on the approved cluster, from the approved image? This check is called attestation. Only then does SPIRE issue a short-lived SVID. The result: no stored secret anywhere. The identity comes from what the workload provably is, not from something it holds.
For years, Bot A signed in with a password in a config file. Nobody had changed it since day one. Anyone who read the file could be Bot A. It was like a house key left under the doormat. After the clean-up, Bot A is registered and has a sponsor. It uses a vault and rotates its secrets. It has only the powers of its refund window. The config file holds nothing worth stealing.
Go deeper: HSMs and SVID lifetime
An HSM is a Hardware Security Module. It is a tamper-proof device that guards keys. Think of it as the vault's vault.
An X.509 SVID lasts about one hour by default.
a canteen that knows staff by face at the till, not by swipe card. There is no card to lose or steal. Recognition stops the day you leave the company. SPIRE is the till. The SVID is the nod that says "this is really them, good for this lunch only".
🧪 Interactive lab — enable JavaScript to play with this one.
Validate your workloads' SPIFFE SVIDs with SPIFFE Scan. Or check workload identity federation from CI to the cloud with OIDC Federation Check.