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
Cheat sheet & pop quiz
You finished the track. Here it is on one page, plus 5 quick questions. Your goal: answer each one before you reveal it.
If you remember nothing else
| Lesson | The idea to keep |
|---|---|
| Set up your coding assistant | Git is your undo button, not the agent. Start on a new branch and run the tests first. Begin in the most careful mode. Set a spend limit on an API key. |
| Give it the right context | Keep the instruction file short. Put in only what the agent can't find or gets wrong. Use one session per task. |
| Plan before it codes | Explore, plan, implement, verify. Write a spec with acceptance criteria. Read the plan before any code changes. |
| Tests, checks and debugging | Test first. Watch the test fail, then commit it. Ask for a fix that does not change the tests. Trust test output, not claims. |
| Review AI-written code | AI code can look right and still be wrong. Check every new package before you install it. Never merge a line you can't explain. |
| Extend your assistant | Text only asks. Hooks enforce. A rule that must always hold goes in a hook or a permission rule. |
| Permissions, sandboxes and secrets | Expect the agent to be fooled sometimes. Rules catch known bad commands. A sandbox blocks the rest. Narrow keys limit the damage. |
| Build an app without coding | Great for a prototype. Browser code is public, so keep secret keys on the server. Test as a second user: can B read A's data? |
| Many agents at once | One agent, one worktree, one branch. Run only as many agents as you can review. |
Pop quiz: 5 questions
Q1 · Priya asks an agent to add dark mode to the admin pages. She comes back to 14 changed files and a new styling library. It also rewrote a shared layout that other teams use. What should she have done first?
She should have written a short spec. It says the goal and which pages to change. It sets limits: no new packages, and don't touch the shared layout. It lists acceptance criteria: checks that show when the work is done. Then she asks for a plan in plan mode. She reads it against the spec and cuts the bad steps. The agent then works in small steps. A mistake caught in the plan costs one sentence. After 14 files, it costs an afternoon. See Plan before it codes.
Q2 · The agent says, "Fixed, all 42 tests pass." The diff changes one line of code. It also changes one line in the test file: toBe(19.99) became toBeCloseTo(20, 0). Is the bug fixed?
You can't tell yet. The test was made looser, so a pass no longer proves the right answer. Reject the test change. Then try inputs the agent never saw. Next time, write the test first and watch it fail. Then commit it. Ask for a fix that doesn't change the tests. A hook or a deny rule on the test folder can back this up. Then any test edit shows up in the diff. See Tests, checks and debugging.
Q3 · A script from an assistant starts by installing a package called excel-merge-tools. The name sounds right. The assistant says it is well known. What do you check, and when?
Check the package page on the registry, before you install. Don't just trust the assistant. Does the exact name exist? How old is it? Who looks after it? Does it link to real source code? Do you need it at all? AI models sometimes make up package names. They often repeat the same made-up names, and attackers register them. This is slopsquatting. Timing matters, because installing a package can run its code on your computer. See Review AI-written code.
Q4 · Priya's rules block the curl command and block reading .env. A hidden order in an issue fools her agent. It writes a small script that reads .env and sends it to an outside server. What stops it? Why did the rules miss it?
The sandbox stops it, if its network is off or limited to a short list of sites. It blocks the connection, whatever command makes it. Permission rules match the text of a command. This script never says curl. It also doesn't use the agent's file tools to open .env. So the rules can't see it. Narrow, short-lived keys also limit what could leak. Plan for the agent to be fooled sometimes. See Permissions, sandboxes and secrets.
Q5 · Priya has 5 tickets. Two change the same dependency file. One renames a field across the whole project. Two are separate bug fixes with failing tests. How should she run agents on them?
Run the rename alone, first. Merge it, and start the rest from there. Give each bug fix its own agent, in its own git worktree and branch. Don't run the two tickets that share a file at the same time. Then review and merge one change at a time. Her review is the real limit. So she runs only as many agents as she can review. See Many agents at once.
Go deeper: a checklist before you hand an agent real work
- Can I throw away all its work with one command? Do I know which tests already failed? See Set up your coding assistant.
- Does it know the commands and traps it can't find alone? See Give it the right context.
- Did I write down what "done" means? Did I read its plan against that? See Plan before it codes.
- Can a check it can't rewrite tell it no? See Tests, checks and debugging.
- Does every package and function it uses really exist? See Review AI-written code.
- Are my must-never rules in a hook or deny rule, not just a sentence? See Extend your assistant.
- If a web page fools it, what can it reach and send? See Permissions, sandboxes and secrets.
- Built it with an app builder? Can a second user read the first user's data? See Build an app without coding.
- Are the tasks I run at once really separate? Do I have time to review them all? See Many agents at once.
That's Coding with AI. You can set up an agent with a safety net and give it good context. You can plan with it and make it prove its work. You can catch made-up packages and keep a fooled agent harmless. You can check an app builder's work for leaks. You can run several agents and stay in control. Next up — Building with AI: build AI features of your own and run them for real. Start the track here.
Try the whole track on a small project of your own. Make a branch and run the tests. Write a short AGENTS.md. Write a spec for one feature and read the plan. Add one hook that blocks edits to .env. Then read the diff before you merge.
Want more? Browse our free security tools on the tools shelf.