UnderDefense MAXI MCP: Your Security Data, in the Harness You Already Work In

Most “AI for security” ends up as a chat window bolted to the side of a console you were already logged into. The model gets whatever the vendor decided to paste into its prompt, the answer arrives in a place you do not work, and the permission model is a new thing somebody now has to maintain.

UnderDefense MAXI MCP is the other approach. It is a remote MCP server: one command in the harness you already have open, and the questions you would otherwise answer by opening six tabs get answered where you are. Claude, Claude Code, ChatGPT, Cursor, VS Code, Codex, Windsurf, Zed, or a harness you wrote yourself.

The interesting part is not that an MCP server exists. Anyone can ship one. The interesting part is what happens to authorization when it does, and that is most of what this post is about.

Key takeaways:

• One command, no API key. OAuth 2.1 with PKCE and dynamic client registration. The harness never receives a MAXI password, tokens expire, and there is no credential written to a config file.
• It inherits the role you already hold. A record you cannot open in the console cannot be returned to a harness either. There is no second permission model to maintain.
• Read-focused, on purpose. It answers questions. It does not modify detection rules, policies or platform configuration.
• Every call goes through a regional gateway that validates the token, resolves the tenant and role behind it, checks the tool against policy, and writes an audit record before anything is queried.
• US and EU are independent deployments. A request to one region is never served from the other.

Add it to your harness → underdefense.com/maxi-mcp

What a connector is actually for

Here is the shape of a Tuesday afternoon. Someone asks why alert volume is up. The honest answer lives in four places: the detections that fired, what was closed as noise and why, which log sources went quiet, and what changed on the external surface in the last month. Each of those is a different view, a different filter, and about four minutes of clicking, so the question either gets a guess, or it gets deferred until someone has an hour.

That is not a data problem. The records exist, and your account can already see all of them. It is a retrieval problem, and retrieval is the one thing a harness with tools is genuinely good at.

So the connector does not try to be clever. It exposes the records your MAXI account can already reach (incident, alert, asset, exposure and compliance data) as typed tools, and lets the model in front of you decide which ones to call to answer what you actually asked. Nothing is exported in bulk. Only the records needed to answer the question asked leave MAXI.

The questions it is built for are the ones that cross views:

Coverage gaps are the interesting case in that list. An endpoint without an agent and a log source that stopped reporting are both silent by nature: there is no alert for the absence of alerts. They are exactly the thing you find by asking, and exactly the thing nobody asks, because asking used to be expensive.

Authorization happens at MAXI, not in the harness

This is the part worth reading slowly, because it is where most connector designs go wrong.

The tempting way to build this is a service account: one identity with broad read access, shared by every user of the connector, with the vendor’s own permission layer deciding who gets what. It is easier to build and it is wrong. It creates a second entitlement model that has to be kept in step with the first one forever, and the day they disagree, the disagreement is a data leak.

MAXI MCP does not have one. The OAuth flow returns a scoped token tied to your identity. SSO and MFA apply exactly as they do in the console, because it is the same sign-in. The gateway resolves entitlements from the role you already hold. If you cannot open a record in the console, the connector cannot return it to you, not because a policy says so, but because the query runs as you.

Offboarding follows from the same property, and it is the test that matters. Disable a user in MAXI and their access through every harness is gone at once (Claude, Cursor, the terminal, whatever else they had configured), because the token was tied to their MAXI identity and nothing else. There is no second list to remember to clean up. Anyone who has ever found a live API key belonging to someone who left eight months ago knows why this is the design.

Every request passes through the gateway

Your harness never reaches MAXI services directly. A regional gateway terminates every session, and three steps run before a single record is read:

• The AI harness turns your question into a tool call and sends it with your access token.
• The regional MCP gateway validates the token, applies tenant and role policy, and records the call.
• MAXI services return only the records your account can see, in the region where your data lives.

The audit record is not an afterthought. Activity through a harness is attributable to a user and a tenant exactly the way console activity is, which means “who asked what, and when” has one answer rather than two. When a reviewer asks how you would investigate misuse of the connector, that is the answer: the same way you investigate misuse of the console.

On residency: US and EU are two independent deployments, and choosing the wrong one is not a performance problem; sign-in simply fails, because your account does not exist there.

Read-focused, and why that is a feature

The connector does not modify detection rules, policies or platform configuration. That is a deliberate boundary, not a roadmap gap.

An agent that can both read attacker-authored text and change your detection logic is a different risk class, and it is not one you should accept in exchange for saving a few clicks. Response actions, case management and evidence retention stay in the console, where there is a human, an approval, and a record of who decided.

This mirrors how we build the AI SOC itself: the agents that touch untrusted content are the ones with the least authority in the system. Same principle, a layer out.

The records contain text an attacker wrote

This deserves to be said plainly, because most vendors will not say it.

Security records are full of attacker-controlled strings. Hostnames, filenames, email subjects, command lines, process arguments: a meaningful share of what comes back from any security platform was authored, at least in part, by the person under investigation. A model cannot reliably tell data it should analyze from instructions hidden inside that data. Nobody has solved that, and a classifier that claims to catch it is selling you an arms race with a fixed win condition for the other side.

So: treat model output derived from MAXI records as untrusted input. If something in a response reads like an instruction that appears to originate from alert data, keep a human in the loop before acting on it. The connector being read-only bounds the blast radius of that problem considerably (the worst case is a misleading answer, not a changed rule), but it does not make the problem disappear, and you should design your own workflows knowing that.

What it will not do

A short list, because the gaps matter as much as the capabilities:

• It is not a system of record. Each response reflects the records retrieved at query time. The console remains the place for response actions, case management and evidence retention.
• It does not train anything. MAXI data is not used to train models. Handling of conversation content follows the terms of whichever harness you are using, which is worth reading, because that part is not ours to promise.
• It does not need anything on your network. A public HTTPS endpoint reached outbound. No inbound firewall rules, no VPN, no on-premise component. If your harness only speaks stdio, the configuration we publish pins a known-good release of the open-source bridge, which you maintain like any other dependency.
• It will not answer beyond your role. Worth repeating, because it is the most common question from security teams and the answer is boring by design.

Installing it

For Claude Code, it is one command in your terminal, run outside any session:

claude mcp add –transport http underdefense-maxi

https://mcp-gateway.us.app.underdefense.com/mcp

Then start a session, run /mcp, select the server and choose Authenticate. Your browser opens the MAXI sign-in page; sign in as you normally would, SSO and MFA included, and approve the access request. claude mcp list confirms it. Add -s user to make the server available in every project rather than only the current directory.

Every other harness is on the install page, region-selectable, with a deeplink where the editor supports one and a copyable config block where it does not.

One caution, and it applies well beyond us: an MCP install deeplink writes server configuration straight into your editor, and the payload is opaque once encoded. Confirm the domain before clicking one, on our page or anyone else’s, and use the manual config if you would rather read what you are adding.

On Team and Enterprise plans, an owner may need to enable the connector for the organization before members can add it. Worth checking before you file a support ticket about a button that did nothing.

The honest summary

It is a well-scoped read path into data you already own, with the authorization model you already run, exposed through a protocol your tools already speak.

The reason that is worth building is narrow and real: the cost of asking a question about your own security posture should be roughly zero, and until recently it was four minutes and a context switch. Most of the questions worth asking never got asked for exactly that reason.

Related reading

• How AI SOC Agents Investigate an Alert, Step by Step
• MAXI MCP: install, capabilities and the security review

Add MAXI to your harness, or bring your security team a question we have not answered. The connector is supported by the same team that runs the platform.