Secure an AXL deployment
An agent is an unusual thing to secure. It reads content you did not write, decides what to do next, and can call tools that change real systems - so the usual perimeter question ("who is calling?") is necessary but nowhere near sufficient.
AXL layers five defenses, each covering a failure the others do not.
| Layer | Answers | Guide |
|---|---|---|
| Shield | Is the content safe to show the model, and the output safe to return? | Configure the shield |
| Authentication | Who is calling? | Authenticate callers |
| Delegated access | What may this user reach downstream? | Reach services as the user |
| Signing | Is this configuration the one we approved? | Verify configuration content |
| Autonomy and approval | May the agent do this without asking? | Create your first agent |
They are genuinely independent. Authentication does not help when a legitimate user pastes a document containing a prompt injection - that is the shield's job. The shield does not stop an authenticated user from reaching data that is not theirs - that is delegated access. And none of them decide whether the agent should have taken an action at all, which is what autonomy is for.
Where to start
If you are securing a deployment for the first time, take them in this order:
- Authentication, because every route needs it and it is the fastest to verify.
- Autonomy, because
require_approvalon a new agent buys you time to learn what it does. - The shield, which is on by default - confirm it rather than configure it.
- Delegated access, once agents start reaching permissioned systems.
- Signing, when the set of deployed agents and skills is stable enough to enforce.