# The AirMemo requester kit **Who this is for:** the person who found AirMemo and wants their team to use it. **What to do with it:** hand this page to whoever owns developer tooling, platform security, or IT procurement where you work. Their approval process asks a predictable set of questions; they are answered below, in the order it asks them. Nothing on this page requires you to run anything. Version 1.0, 2026-10-07. Live copy: https://airmemo.com/requester-kit.md --- ## 1. The request, in one paragraph AirMemo is governed memory for AI coding agents. Your company's in-force decisions - the current answer on a project, a released policy, a corrected fact - are delivered into the session context of the AI coding agents your engineers already run: Claude Code, Codex, Cursor, GitHub Copilot, and Gemini CLI. Each delivery is scoped to your organization, authorized by an owner or administrator, bound to an expiry date, and receipted, so the organization can show what each agent was told. It is not a chatbot, not a model, and not a store of your source code. It is the layer that decides what an agent is told next, and proves it. Source: https://airmemo.com/mechanism; https://airmemo.com/security section 2. ## 2. What it touches, and what it does not **It does not ingest your repository, your conversations, or your terminal output.** AirMemo is not a retrieval index over your codebase; it delivers author-written memos, and nothing else. | Question | Answer | | --- | --- | | What leaves a developer machine? | A request from the AI client to https://api.airmemo.com/mcp over HTTPS, carrying the organization's token. | | What does AirMemo store? | The organization's memos (author-signed text) with their scope, priority, expiry and approval state; and delivery receipts (which memo reached which agent, when, and a proof hash of what was delivered). | | What does it never store? | Source code, prompts, chat history, credentials. Secret scanning runs at author time and again at delivery, and matched values are never stored. | | How long is data kept? | Memos age out of the live set after the retention window stated in the Privacy Policy and the DPA. | | Is usage tracked? | Telemetry is opt-in and off by default. Receipts, not analytics, are the record of what was delivered. | Source: https://airmemo.com/security sections 2, 3 and 4; https://airmemo.com/privacy section 5; https://api.airmemo.com/data-processing-addendum.md section 8. ## 3. The credential - **What it is:** an organization API token, created in the AirMemo console by an owner or administrator (Settings, then API tokens). - **What it grants:** two scopes. Reads require memos:read. Proposing new context additionally requires memos:create. A read-only integration needs the first scope only. - **How it is limited:** tokens are short-lived and revocable, and every call is rate-limited, scope-checked and audit-logged server-side. - **What is not used:** there is no OAuth flow in this release. The bearer token is the credential, the same model as the REST surface, so there is no third-party identity provider to trust or configure for the integration to work. Source: https://airmemo.com/docs (the API and doc index); https://airmemo.com/security section 3. ## 4. How an agent connects The endpoint is https://api.airmemo.com/mcp. It speaks MCP (Model Context Protocol) over Streamable HTTP, and it exposes five tools (see the appendix). The connection is **human-approved and token-authenticated**. The person connecting adds the server to their own client and supplies the token; AirMemo does not write a client's MCP configuration on its own. There is no script to run that configures a developer's tools without that developer clicking. The exact per-client setup steps are on the connect page: https://airmemo.com/connect Source: https://airmemo.com/connect; https://airmemo.com/docs. ## 5. What your administrator approves Two things, and neither happens without a person in your company deciding it. **An organization API token.** An owner or administrator creates the organization in the console and mints a token with the scopes above, then hands it to the requester. That is the approval. Reads are then scoped to that organization and nothing else: a token from one organization cannot read another organization's context. **A device enrollment (only for organization-wide delivery).** The deeper integration installs a small hook that rides the lifecycle events an agent already exposes, so memos reach every enrolled agent rather than one client. Enrolling a device lands in a PENDING state and consumes nothing until an owner or administrator approves it in the console; revoking it frees the seat. **Proposals are never silent.** The one tool that writes (propose_context) does not publish anything. It files a pending draft that an owner or administrator approves in the console before any memo is enqueued. It cannot bypass that review. Source: https://airmemo.com/security; https://airmemo.com/pricing; https://airmemo.com/docs. ## 6. The one-request path This is the whole ask. You do not need anyone to install anything first. 1. Send the person who owns developer tooling or platform security one message: you would like AirMemo evaluated for the engineering organization. 2. Attach this page. It answers the standard intake questions above. 3. If they want the security detail, they have it: the whitepaper, the DPA, the Privacy Policy, the Terms, and the machine-readable trust index are all public (links in section 7). 4. If they want to try it before approving, ask for a pilot workspace. That conversation starts at https://airmemo.com/talk and needs no procurement step. 5. For approval: an owner or administrator creates the organization and mints a scoped token (section 5). The requester then connects their own client with that token (section 4). 6. For organization-wide delivery, the administrator approves each enrolled device in the console. Two things make this a governed request rather than a shadow install: the credential is issued by someone in your company, and every read is org-scoped and logged. If nobody approves a token, nothing is delivered. ## 7. Security documents and standards posture Public and readable today: - [Security & Trust Whitepaper](https://airmemo.com/security): controls, receipts, and the explicit deferred list. - [Machine-readable trust index](https://api.airmemo.com/trust) and the raw [whitepaper](https://api.airmemo.com/security-whitepaper.md). - [Data Processing Addendum](https://api.airmemo.com/data-processing-addendum.md): processing terms, sub-processors, breach notification. - [Privacy Policy](https://airmemo.com/privacy): what is collected and for how long. - [Terms of Service](https://airmemo.com/terms) and the [Acceptable Use Policy](https://airmemo.com/aup). - [Docs](https://airmemo.com/docs): the hook, the per-vendor adapters, receipts, enrollment. **What is shipped:** SSO, SCIM directory sync, and MFA, all documented in the whitepaper and verified end-to-end against a test identity provider by the contract suite. **What is deferred, stated plainly so it is not mistaken for a claim:** - **SOC 2:** not certified and not claimed. Work starts when enterprise pipeline reaches $100,000 or the first cloud deal signs, whichever comes first. - **EU data processing residency:** a documented migration item, not a storage guarantee. Cloud processing is currently split across US East and US West; an organization's region setting is a recorded claim, and the whitepaper says so. - **SAML and usage-based billing:** deferred. Source: https://airmemo.com/security section 4 (the deferred list and the SOC 2 gate); https://airmemo.com/security section 4.1 (residency); https://airmemo.com/docs (the SOC 2 gate wording). ## 8. Appendix: the five tools - search_context: ranked search over the organization's in-force context. - get_decisions: the organization's in-force decision set. - get_memo: one memo's body, signature, and delivery chain. - whoami: organization identity, granted scopes, and token details. - propose_context: files a draft memo into the approval flow. Never a silent write. Of these, only propose_context writes, and it writes a pending draft, not a published memo. Source: https://airmemo.com/docs; https://airmemo.com/llms.txt.