Resources
Guides
How to govern AI agents, introduce AI permissions, implement human approval, audit AI actions, manage multiple models and discover shadow AI.
All six are answered
Every subject a guide would cover already has a page written for that question. What a guide adds is sequence — the order to do things in, and the decisions you make on the way.
Subjects
6
Guides written
0
Six questions
No guides written yet. All six subjects are already covered.
Which makes the useful thing here a set of pointers rather than an apology. Each of these is a page written for exactly that question, and each is more thorough than a guide would be at explaining the mechanism.
- How do I govern AI agents?
- What an AI system is here, why the framework it was built in does not matter, and where a control attaches so it covers paths nobody has written yet.
- The inventory and the ladder
- How do I introduce AI permissions?
- Three layers that can only narrow: what a connection permits at all, what a system may attempt, and whether this particular instance is allowed.
- Identity and grants
- How do I implement human approval?
- When a person belongs in the path, what they are shown, and the part most designs get wrong — that a hold expires rather than queueing.
- Approvals
- How do I audit AI actions?
- What a sealed, chained record contains, why refusals are recorded as completely as successes, and how to verify the chain without taking our word for it.
- Audit
- How do I manage multiple models?
- Making the choice of model a governed rule instead of a constant in a repository, and why a rule cites a requirement of yours rather than a comparison.
- Model routing
- How do I discover shadow AI?
- Reading the systems you already run — the identity provider, the egress proxy, the SaaS admin console — and why the headline is corroborated findings rather than raw detections.
- Discovery
Why the section is empty
Nothing has been written, and no date is being offered for one.
A guides section with three thin posts is worse than an empty one, because it implies the shallow version is the intended depth. This says what a guide will contain when there is one.
Guides
Writing a guide well takes longer than writing a reference page, and publishing a shallow one to fill the section would set the wrong expectation for the ones that follow. The subjects above are covered properly in the meantime.
What it will contain
- A sequence rather than a mechanism: what to do first, and what to defer.
- The decisions you have to make on the way, with the tradeoff on each.
- Where teams commonly get it wrong, which a reference page has no place to say.
- A worked example against the sample estate, so every figure is checkable.
If you want the mechanism
The documentation covers concepts, policy syntax and lifecycle, security, and the API — nine pages, read in order or dipped into.
If you want a sequence
The quickstart goes from nothing to a governed action in five steps, and ends on a refusal rather than a success.
Where to go
Start with the subject that matches what you are trying to do this week.
Each of the six above is a complete answer to its own question. The guide that will eventually sit here adds the order to tackle them in, and that is a smaller gap than an empty section makes it look.