▸ Procurement-friendly · security-readable · engineering-adoptable
The premise
Your engineers are already running agent harnesses — Cursor, Claude Code, Windsurf — with or without you. AADM gives the org a standard those agents load on every turn, so adoption stops being a per-engineer security risk.
AADM is built for orgs where “the model shipped it” isn't an acceptable incident report. An open standard your security team can read, a hosted service your platform team can wire once, and engineering discipline your reviewers stop having to argue for.
Building the internal case with your staff and principal engineers? Agentic engineering makes the argument in their language — where twenty years of judgment now creates leverage, rather than why they should tolerate a new tool.
AADM is opinionated about what it is — and aggressive about what it is not. The boundary is the product.
The MCP server does not scan your repository, mutate your database, or run your business logic. It returns versioned text and structured JSON — that's it. The blast radius of any agent call is bounded by what your IDE and your CI already allow.
The AADM standard lives in public on GitHub. Your security and compliance teams can read every workflow, control reference, and seam definition. There is no proprietary black box behind what the agent loads.
AADM describes how controls should apply. Your production gateways, services, and CI prove enforcement. The MCP never claims a release is “certified” — its language is recommendation, not verdict.
Procurement
Open standard text · Bearer-token or OAuth auth · no scanning of your repo · managed authentication for identity · operational telemetry only. Brief security and skip the long RFP.
Platform & DevEx
One hosted MCP, one Streamable HTTP endpoint. Versioned tools, deterministic routing, capability bumps on your schedule. No per-team prompt sprawl.
Security & compliance
Audit programs, seam closure, AUTH references — your evidence gets a structure an auditor will accept. The MCP doesn't certify anything; your apps and CI still prove enforcement.
The questions your security team is going to ask anyway. Paste them into your RFP and skip the back-and-forth.
Does the MCP see our source code?
Short answer
No. The MCP server returns versioned standard text and structured JSON. It does not have network access to your repo, your branches, or your CI. Your IDE and your agent read code locally — the MCP is told nothing about it.
Where does authentication happen?
Short answer
Authentication is handled through our login area. Subscribers receive either a Bearer API key (ak_…) or an OAuth client ID — both are managed in the member area. Tokens never need to leave your IDE; we don't see your IDE keystrokes.
What is logged on the server side?
Short answer
Operational telemetry for service health (latency, error counts, tool-call rates) — not request bodies, not your code, not your conversations. Treat the MCP like any other governed SaaS API your platform team would approve.
Can we self-host?
Short answer
The hosted MCP is the recommended path — versioned, maintained, and on rails. Talk to us about self-hosting if you have a hard data-residency requirement; the standard repo is open so you have leverage.
How do we rotate tokens?
Short answer
Tokens are managed in the AADM member area. Revoke and reissue without redeploying your IDE config — paste the new token into the same mcpServers.aadm block.
Who is responsible for what?
Short answer
AADM is responsible for the standard and the running service. You are responsible for your codebase, your AUTH enforcement, your tests, your CI. The MCP makes it easier to encode and enforce the boundary; it doesn't move it.
Adoption is a per-engineer paste. You don't need a quarter of platform work to prove value.
I
One senior engineer
Connect Cursor or Claude Code with a single Bearer token. Run an Investigator lane on a real defect. Watch the evidence-before-fix discipline hold in their session, on code they know well enough to judge it.
II
A whole squad
Roll out the same MCP endpoint to the team. Optional · drop a versioned .aadm/config.json into the app repo so UDALI paths and lane defaults stay shared.
III
Multiple teams · multiple harnesses
Standardize on the hosted MCP across every MCP-capable harness in use. Discipline becomes deterministic across the engineering org — even with contractors and new hires.
Engineering adoption starts with a single paste in a single IDE. The standard, the hosted service, and the answer to your security team's questions are all already public — start there.