> ## Documentation Index > Fetch the complete documentation index at: https://docs.try-airlock.com/llms.txt > Use this file to discover all available pages before exploring further. # Airlock > The security layer between your organization's knowledge and everyone who touches it; people and AI agents alike. Organizations are handing internal knowledge to AI agents faster than they can answer basic questions about them. Airlock records **who accessed what, through which tool, on whose behalf** — people and agents in one stream — and surfaces the agent decisions worth a second look. ```sh theme={null} cd ~/code/some-repo airlock claude # a fully sandboxed, fully attributed agent session ``` ## The problem it solves An agent reads a thousand documents in the time a person reads one, acts on behalf of whoever prompted it, and reaches whatever its network allows. Three questions follow, and most organizations cannot answer any of them: * **Who was that?** An agent session with no identity behind it is an audit gap, not a log line. * **Where did it go?** Data leaves through an agent's egress as easily as through a person — prompt injection included. * **Can that decision be trusted?** When an agent's output moves money or closes a case, "it said so" is not a record. ## What Airlock does Every agent act becomes one identity-attributed event (access, chat, and decisions) from the sandbox, SaaS audit logs, and a push API for agents anywhere. Agent decisions are flagged when they cite nothing, report low confidence, or contradict another decision on the same target. Roles and self-view, employee notice, and action gates where an agent's next step cannot be taken back. Runs in your VPC. The backend makes no outbound connections. ## The agent runtime Airlock's own sandbox is the deepest capture surface: The repo is mounted read-write at `/`. Your home directory, `~/.ssh`, `~/.aws`, and every other repo simply do not exist inside. The sandbox sits on an internal Docker network with no route out. Its only exit is the Airlock proxy — allowlist by default, blocklist when you would rather not gate the team, logged either way. Allowed or denied, each connection is logged with the user behind it, plus path, byte counts, and duration. The agent gets its own isolated home. Credentials live outside every repo, and tokens never enter a container. ## Then: from record to review ```sh theme={null} airlock publish # transcripts + egress → your self-hosted backend open http://localhost:4747 # the console: login, timelines, flags queue ``` Every session lands in a store you operate, and the [console](/dashboard) — login-gated and role-scoped — turns it into a record a security team can review. Non-admins see their own activity, not anyone else's. ## Next steps Install the CLI and open your first sandboxed, attributed session. The capture plane, the review plane, and the boundary between them. The agent runtime, push ingestion for agents anywhere, and SaaS audit connectors. Decision flags, and the evidence behind each one. Timelines, sessions, and the flags review queue. Accounts, roles, notice, and egress posture.