Start with the sentence nobody wants to write
Elaichi has no FedRAMP authorization. It is not in process, and it is not listed on the FedRAMP Marketplace. Nothing in this post should be read as implying otherwise. Your agency, your prime or your contract may require a FedRAMP-authorized service for the data the agents will touch. If so, the honest answer for fedramp mcp ai agent access is simple: do not buy Elaichi for that workload yet.
That sentence costs us deals. It also saves both sides a two-month evaluation that ends in the same place. The rest of this post is for the reader somewhere adjacent to that boundary. A contractor doing unclassified corporate work. A state or municipal buyer with a FedRAMP-inspired checklist rather than a mandate. A company that sells to federal agencies while its own finance and support teams run on commercial SaaS. Those readers have a real question, and it is not "are you authorized". It is "what can you show me about how an AI client reaches our apps".
What does fedramp mcp ai agent access actually require?
FedRAMP authorizes a cloud service offering against a control baseline. The route runs through an agency sponsor or the Joint Authorization Board, and the result is published on the FedRAMP Marketplace. There is no partial credit. A vendor is listed or it is not.
So the first question in any evaluation is a boundary question, not a product question. Which data will the AI client reach? Does that data sit inside a system that requires an authorized service? If the agents will read case files, citizen records or controlled unclassified information, stop here. The other case is a company with federal customers whose agents read its own Jira tickets, Zendesk queue and expense tool. There the boundary is usually the corporate IT estate. The reviewer is then asking a different question: can you prove who did what, and can you stop it.
MCP is the protocol an AI client uses to discover and call tools. An MCP endpoint is the single address a client signs into, and MCP clients include Claude, ChatGPT and Cursor. Each vendor documents how an administrator introduces a remote MCP server. Anthropic documents adding a custom connector on Claude Team and Enterprise plans (support.claude.com, checked October 2026). OpenAI documents developer mode and custom MCP apps, which admins and owners enable on Business workspaces (help.openai.com, checked October 2026). Cursor documents shared Team MCP servers that team admins distribute (cursor.com, checked October 2026). The governance question is what sits at that address.
What a US region covers, and what it does not
An Elaichi organization picks a region when it is created: EU, US or APAC. The choice cannot be changed afterward. It is a provisioning decision, not a setting.
For a US organization, the per-organization data store stays in the US. That store holds members, teams, roles and role assignments. It also holds sharing lists, invitations, connections, toolboxes, templates, restrictions, synthetic tools, access requests and MCP OAuth grants. Org-scoped requests run in that region too, through a per-organization region gateway. A connected-tool call fetches the account's credential and applies it there. The outbound request to Salesforce or Zendesk is sent from that gateway, and its response is handled there.
Now the parts that are not in the US, which a reviewer will find anyway.
Elaichi's shared database and its short-lived caches are not pinned to a region. User accounts, the organization row, API tokens and SSO connections live in that shared database. Sessions, MCP OAuth authorization requests, access tokens and refresh tokens live in the caches. Some requests do not act inside an organization at all: sign-in, sign-up, the OAuth registration, authorization, token, revocation and userinfo endpoints, and webhook intake. Those run wherever the request lands rather than in the region gateway.
Every organization's audit trail, whatever its region, is stored in one log instance in the EU. The privacy policy, the DPA and the GDPR page say so in the same words. A US buyer may have assumed the audit log follows the organization's region. Read /privacy/ and decide whether that is acceptable before the pilot, not after. Files Elaichi stores from tool results are also kept in the EU for every organization.
APAC is weaker still: placement is best effort, not a residency guarantee. For the leg-by-leg version of this analysis on the European side, see EU data residency for AI agents.
Append-only audit and per-organization log tenancy
The audit log is append-only. Elaichi's log client can only insert and query records. The audit API has one read route, and no route edits or deletes an entry. A reviewer asking whether an admin can quietly remove a row gets a structural answer rather than a policy promise.
Each organization has its own tenant in the log store, assigned once and never reissued, even after the organization is deleted. Tenancy travels in headers the worker sets, never inside the query text. The customer read path refuses to query anything but the customer-visible project, so a scoping mistake returns nothing rather than another tenant's records.
The log records the acting person, the toolbox and the connector for each connected-tool call. It also records the tool's advertised and catalog names, the connection the call reached, and the tool's classification. Each row carries the surface as well: console, api, mcp or app. When the surface is mcp, the row names the MCP client's id. It also holds whether approval was required and how it was given, the outcome, and what the call touched. Argument values are not recorded, with one exception. The one path argument that names the object is recorded as the target id. Reviewers comparing vendors on this point will want the side-by-side of audit record shapes.
Two limits a reviewer should hear from you rather than discover. Elaichi keeps 90 days of audit history. A longer history means forwarding to your own log service, and logging destinations come with the Black plan, which is launching soon. And not everything is an audit entry. A call refused at the MCP scope check writes no row, because that refusal happens before any executor runs. For the full field list, see what an AI agent audit log must capture.
Customer-managed keys: a Black-plan item, launching soon
Connector secrets are encrypted at rest with AES-256-GCM. Each stored value records the key that wrote it, so the encryption key can be rotated without re-encrypting old rows. Credentials are not kept in Elaichi's main data at all. A separate credential service holds them, and they are fetched into memory only for the call that needs them.
Customer-managed keys in AWS KMS come with the Black plan, which is launching soon. Black is not on sale today and has no published price. If a reviewer's checklist makes customer-managed keys a condition of award, that is a second reason to wait rather than buy.
When the answer is wait, and when it is not
Wait if any of these is true. The data in scope requires a FedRAMP-authorized service. Your contract names an authorization as a condition of award. Your reviewer treats customer-managed keys as mandatory rather than preferred. Your retention requirement exceeds 90 days and you cannot wait for Black to forward the log to your own Datadog. Or your residency requirement covers the audit trail as well as the operational data. That trail sits in the EU today.
Proceed, carefully, in three cases. The workload is your own corporate estate rather than a federal system. Your reviewer's real question is attribution and revocation rather than an authorization line item. And you can run a scoped pilot with read-only toolboxes on one team. In that case the evaluation looks like a normal security review. The checklist in MCP security review checklist covers the questions to ask any vendor at this address.
What to put in front of a reviewer
Give them five artifacts rather than a narrative. First, the region decision and its scope. A US organization keeps its data store and its request execution in the US. Its audit trail and stored files sit in the EU. Second, the access model. A member holds exactly one role, and restrictions target a role or one member. A restriction change takes effect within about two minutes. Third, the identity model. Every call acts as the person who approved the grant, and each person connects their own client. Removing or suspending a member revokes their grants, so their clients fail on the next call. Fourth, the audit sample, with the surface and MCP client fields visible. Fifth, the Trust Center at https://trust.elaichi.ai for certification artifacts, which is where those claims belong rather than in a product page.
Then name the gap in the same document. A reviewer who finds the FedRAMP gap themselves, after four weeks, treats everything else you said as marketing. A reviewer who reads it in your first response treats the rest as evidence. If the gap arrives as a questionnaire instead, twenty prepared answers on AI agent access cover most of what a reviewer sends.
For the broader buyer's framing of this category, enterprise MCP covers what IT teams evaluate before residency and authorization come up. The governance use case shows what the controls look like in the product.
