How AI coding agents get production access safely

Same access. Same rules. AI included.

Hoop's user MCP server lets AI coding agents reach your internal databases, servers, and services using the permissions of the human user they are working for. Every action runs through the same policies, approval workflows, and audit logging that apply to humans. Identity federation via OAuth 2.1 means the agent has no separate credentials and no separate access policy.

Why it matters

A developer asks her AI agent to "find the user who placed order #42389 and check if their last login looks suspicious." Today, that means giving the agent a database credential with broad read access to the customer table. The agent runs the query. Nothing in the audit log says it was her asking. Only that the agent's credential ran a SELECT.

This is the gap most teams hit in week three of any agent rollout. The agent works. Nobody can explain what it did, on behalf of whom, or whether it had permission.

The fix is not a new layer of AI-specific policy. The fix is making the agent run as the human it is working for.

What we shipped

Eight MCP tools that turn any Hoop user into an AI-agent operator. The full list:

me_get: confirms which user the agent is authenticated as
exec: runs a one-shot query against any connection in the catalog
connection_databases, connection_tables, connection_columns: schema discovery on database connections
sessions_get_content: pulls input and output of a past session
sessions_get_analysis: fetches Hoop's AI analysis of a session
sessions_wait_analysis: long-polls until the analysis is ready
reviews_execute: runs an approved query after a human reviewer signs off
reviews_wait: long-polls a review until it reaches a final state

Every call goes through Hoop's policy engine. Data masking applies. Approval workflows apply. Sessions get recorded with the human user as the source identity.

The graceful approval pattern

The most interesting tool in the set is exec. When an AI agent runs a query through exec, three things can happen:

The query is allowed and runs. The agent gets results.
The query needs approval. The agent gets a review_id and a pointer to reviews_wait.
The query takes longer than 50 seconds. The agent gets a running status and can long-poll for completion.

The agent does not fail when it hits an approval gate. It waits. We call this the graceful approval pattern, and it is the right shape for AI agents that need to operate in environments where humans normally approve sensitive actions.

Continue reading? Get the full guide.

AI Model Access Control + Customer Support Access to Production: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Here is what graceful approval looks like in practice. The agent calls exec with a DELETE on the production users table. Hoop's policy engine flags it: DELETE on a high-risk table requires a reviewer. The exec call returns pending_approval with a review_id. The agent calls reviews_wait with that ID. A human reviewer opens the request, reads the query, approves. The agent calls reviews_execute(review_id). The original DELETE runs.

The audit log shows the full chain: agent attempted a DELETE on behalf of user X, reviewer Y approved at timestamp Z, the DELETE ran with the approved input.

The security-critical detail is that reviews_execute runs the stored input only. The agent cannot submit one query for approval and then run a different query after the human signs off. Approval and execution are bound to the same query. No drift between what the human approved and what the agent ran.

How this compares to other approaches

The shape of the problem is well-known. Three patterns are common today:

Direct database credentials. The agent gets a static API key with broad permissions. The agent can do everything the credential can do, no matter who is asking. The audit log records the credential, not the user.
API gateways with bearer tokens. The agent gets a token scoped to specific endpoints. Better isolation, but no human-level context. The audit log records the token, not the user.
MCP servers without identity federation. The agent connects to internal tools through MCP, but the connection uses the agent's own identity. Either every agent gets the same elevated access, or every agent requires its own per-agent provisioning.

Hoop's user MCP server is different. The agent calls infrastructure with the permissions of the human user who started the session, scoped through OAuth 2.1. Same policies as humans. Same audit trail as humans. No second framework to maintain.

What changes for you

Three things shift the day you turn this on:

Your agent is no longer a separate identity. It is the user it is acting on behalf of. Permissions, group memberships, ABAC rules, time-bound access. All of it carries over.

Your audit trail collapses to one timeline. Every session, human or agent, lives in the same log. You query by user, not by "did a person or a machine do this."

Your agent can read its own history. The sessions_get_content and sessions_get_analysis tools let the agent pull past sessions it ran, including Hoop's AI analysis of what happened. The agent can debug itself, learn from prior runs, or surface patterns to the human user.

What this pairs with

The user MCP server uses OAuth 2.1 to federate identity. Tomorrow we ship the second half: MCP OAuth configuration, which lets your existing identity provider issue the JWTs that the user MCP server validates. Standards-based, per-org, backward compatible with the existing token model.

The two together close the loop. Your IdP authenticates the user. The user grants the agent OAuth-scoped access. Every call the agent makes runs through your access policy with your identity attached.

The bigger picture

Last week we shipped the admin MCP server: automation for the people who run Hoop. This week we ship the user MCP server: access for the AI coding agents your engineers are already using to write code.

Same architecture both times. AI agents don't get a governance exemption. They work inside the rules everyone else does.

Definitions

MCP (Model Context Protocol) is the standard way AI agents discover and call external tools, introduced by Anthropic in 2024.
Hoop is an access gateway that sits between engineers, AI agents, and production infrastructure. Every action runs through Hoop's policy engine, data masking, approval workflows, and audit trail.
Identity federation for AI agents means the agent inherits the permissions of the human user who started the session, rather than getting its own credentials.
Hoop's user MCP server is the surface that lets AI agents call Hoop tools as if they were the human user.
The graceful approval pattern is the design where an AI agent's request to perform a sensitive action does not fail when it hits an approval gate. The agent waits for a human reviewer, and the originally-submitted query is the only query that can run once approved.