2. The Corporate MCP Threat Model

Before designing defenses it helps to be precise about what you are defending against. An MCP server that exposes internal data — customers, schedules, payments, source code — is a much more attractive target than an arbitrary REST API, because it advertises a typed catalog of operations to anyone who can list its tools. The discoverability that makes MCP useful for an LLM also makes it useful for an attacker who has stolen a token.

2.1 Who is on the other end of Bearer ...?

Every authenticated MCP request arrives with an Authorization header. Your server has to answer two questions before doing anything: is this a real token issued by an identity provider you trust, and which human does it represent? Skipping either answer collapses authentication into "the request looked like JSON", which is no authentication at all. The dual JWT / opaque-token handler shown later in Section 5 exists specifically because answering the first question correctly is harder than the tutorials usually admit.

2.2 What can a stolen token do?

Assume the token will be stolen. A laptop is lost, a developer pastes a token into a Slack channel, a malicious browser extension exfiltrates session storage. The question is not "how do we prevent every leak" but "how much damage does a single leaked token do before it expires?" Limiting blast radius means short-lived tokens, minimum scopes, and an authorization layer that does not assume a valid token implies valid intent.

2.3 Insider misuse versus external attacker

External attackers are the loud threat; insider misuse is the quiet one. A rostered employee with legitimate access to one tool may try to invoke another that nobody has ever audited. A per-tool ACL stops that, and an audit log makes the attempt visible to whoever owns incident response. Without both, the answer to "who pulled that report on Friday night" is a shrug.

2.4 Data exfiltration through tool composition

An LLM client is a confused deputy by design: it composes tools on a user’s behalf, but it has no idea which compositions the user is actually entitled to. If your read tool returns customer records and your write tool sends emails, an instruction embedded in a record can ask the model to email a competitor. The defenses here are the same defenses you would apply to any API: scope the tools tightly, never let one tool’s output drive another tool’s side effects without a human in the loop, and log everything.

Threats this article addresses, mapped to later sections:

·       Forged or stolen tokens → Section 5 (authentication, audience, hosted-domain)

·       Over-broad access by valid users → Section 6 (per-tool roster)

·       Insider misuse → Section 7 (audit log of every call)

·       Eavesdropping in transit → Section 8 (TLS, forwarded headers)

·       Secrets in source control → Section 8 (configuration management)

3. The Pillars of Cybersecurity: A Working Vocabulary

The rest of this article uses six recurring words. They are the standard vocabulary of practitioner security: the classical CIA triad of Confidentiality, Integrity, and Availability, plus Authentication, Authorization, and Auditing / Non-repudiation. Each definition below is short on purpose; the implementation details are in the code sections, and Section 9 contains a single table mapping every pillar back to a specific file in the codebase.

3.1 Confidentiality

Information is only readable by the people meant to read it. In an MCP context this means tokens are not visible on the wire (TLS), database credentials are not visible in source control (vaulted secrets), and tool responses are not delivered to unauthenticated callers. Implemented here via HTTPS redirection in Program.cs and configuration-based secrets, see Section 8.

3.2 Integrity

Information cannot be modified in transit or at rest by an unauthorized party, and the server can prove it. Cryptographic signatures on JWTs, parameterized SQL queries that resist injection, and a re-check of the OAuth audience claim are all integrity controls. Implemented here in the JWT validation parameters and tokeninfo handler shown in Section 5, and the Entity Framework patterns referenced in Section 8.

3.3 Availability

Authorized callers can actually use the system when they need it. This usually shows up as cache, throttling, and timeout policy, but it also means a missing config file should fail loudly at startup rather than silently degrade in production. Implemented here as a fail-fast roster loader, a reused HttpClient that prevents socket exhaustion, and a configurable database command timeout.

3.4 Authentication

Proof of identity. "This request is from a real person at a real company." In this codebase the proof is a Google-issued token, validated either as a signed JWT or by introspecting an opaque access token at Google’s tokeninfo endpoint. The hosted domain and verified-email checks make sure the identity is from your Workspace, not any random Gmail account.

3.5 Authorization

What an authenticated identity is allowed to do. Authentication answers "who"; authorization answers "may they call this specific tool right now?" Implemented here as an opt-in [ToolAccess] attribute, a custom AuthorizationHandler, and a per-user-per-tool roster loaded from a JSON file at startup.

3.6 Auditing and Non-repudiation

An immutable record of who did what, when. A user cannot plausibly claim they did not call a tool if there is a timestamped log entry tying their email to the tool name. Implemented here as a thin middleware that runs after authentication and extracts the JSON-RPC method and tool name from each request body.

4. Setting Up Google Cloud: OAuth Consent Screen, Client ID, Hosted Domain

Before writing a single line of .NET, the OAuth handshake has to exist on Google’s side. The configuration there sets the perimeter of who can even attempt to authenticate. Get this wrong and your server-side checks become the only line of defense; get it right and you have two layers, with Google’s identity provider doing most of the work.

4.1 Create the project and enable the OAuth consent screen

In the Google Cloud Console, create a new project for the MCP server (or reuse an existing one belonging to the team that owns it). Open APIs & Services → OAuth consent screen and start configuring. The single most important field on this screen for a corporate MCP server is the User Type radio button. Choose Internal. "Internal" pins the consent screen to your Google Workspace organization — only accounts in your Workspace can ever see it, and Google will refuse to issue tokens to anyone else. Personal Gmail accounts are blocked at the identity-provider layer, before they ever hit your server.

Fill in the App Name (for example "Shopsnap MCP"), the user support email (an owned alias such as mcp-support@shopsnap.com), and the developer contact email. The branding fields are not security-critical but they are the first thing your users see in the OAuth consent dialog — a polished consent screen reduces phishing risk by training users to expect a specific look.

4.2 Create the OAuth 2.0 Client ID

Under APIs & Services → Credentials → Create Credentials → OAuth client ID, choose Application Type: Web application. The redirect URI you authorize here must match whatever URI your MCP client (Claude Desktop, a custom CLI, an internal portal) uses to complete the OAuth flow. For Claude Desktop and most loopback-flow clients, this is a localhost URL on a high port; for a server-rendered client, it is your own callback endpoint.

The scopes you request from Google should be the minimum needed to identify the user. For an MCP server that does no Google API calls of its own, openid email profile is sufficient. These three scopes give you the user’s identity, their verified email, and their basic profile — nothing else. Asking for more is a violation of least privilege and an unnecessary entry on the consent screen that may make users suspicious.

Save the Client ID. You do not need the client secret for this server because validation happens server-side using Google’s public key set (JWKS) for JWTs and Google’s public tokeninfo endpoint for opaque tokens. The client secret would be needed only if your server itself was performing the OAuth flow on behalf of a user, which it is not.

4.3 Hosted-domain restriction

The Internal user type already restricts authentication to your Workspace, but the .NET server will also enforce a hosted-domain (hd) check on every token. This belt-and-suspenders pattern matters because configuration drift is real: someone may flip the consent screen to External in a year, or a future MCP client may use a flow that bypasses the consent screen entirely. The server-side hd check is the invariant that survives those changes.

Warning: Choosing "External" on the consent screen lets any Google account through Google’s side of the handshake. The server’s hd and email-suffix checks will still reject them, but you have lost defense in depth and exposed the consent screen to the entire internet.

With the consent screen and client ID in place, you have three values to feed the server: the Client ID (e.g. <YOUR_GOOGLE_CLIENT_ID>.apps.googleusercontent.com), the authority (https://accounts.google.com), and the hosted domain (shopsnap.com). These land in appsettings.json under the GoogleAuth key, shown in Section 8.

5. Wiring Authentication in ASP.NET Core

This is the longest section in the article because authentication is where most corporate MCP tutorials get something wrong. The ASP.NET Core JwtBearer middleware is excellent at validating signed JWTs, but Google’s OAuth flow can return either a JWT (the ID token) or an opaque access token (a string like ya29.xxx). Most MCP clients send the access token. JwtBearer cannot validate an opaque token because there is nothing inside it to validate — you have to introspect it at Google’s tokeninfo endpoint. The code below handles both cases.

5.1 The extension method and DI shape

All Google-related authentication setup lives behind a single extension method. The Program.cs caller does not need to know about JWT bearer schemes, MCP authentication schemes, or tokeninfo — it just calls AddGoogleMcpAuthentication and is done. Listing 1 shows the entry point and the dual-scheme registration.

Listing 1: AddGoogleMcpAuthentication entry point

Two schemes are registered, with different responsibilities. JwtBearer is the default authenticate scheme — it inspects every incoming Bearer token and produces a ClaimsPrincipal. The Mcp scheme is the default challenge scheme — when an unauthenticated request arrives, it produces the protocol-correct 401 response with the protected-resource metadata that MCP-aware clients use to discover the auth server. Splitting the two responsibilities is what lets MCP clients negotiate authentication without you having to write any of that handshake yourself.

Notice the fail-fast pattern in the configuration reads. Missing ClientId or Resource throws at startup, not on the first authenticated request. This is an Availability control: the operator finds out about a misconfigured deployment in seconds, not after a user has already filed a confusing bug report.

5.2 Token validation parameters

JwtBearer needs to know what a valid token looks like. Listing 2 is the configuration block that pins the validator to Google’s issuers, your client ID as the audience, and standard signature and lifetime checks.

Listing 2: TokenValidationParameters for Google JWTs

Two settings deserve a closer look. ValidIssuers contains both the URL form and the host-only form because Google has historically used both, and a strict comparison against just one will reject perfectly valid tokens. ValidAudience is set to your OAuth client ID — this is the integrity guarantee that prevents an attacker from presenting a token minted for a different application. Without the audience check, any Google-signed token from any OAuth client in the world would pass signature validation here.

NameClaimType = "email" tells ASP.NET Core that ctx.User.Identity.Name should return the email claim, which is what the rest of the pipeline expects. The MapInboundClaims = false setting (configured one line above) preserves Google’s original claim names like hd and email_verified instead of remapping them to the older Microsoft URI-style claim names. The authorization handler depends on those raw names.

5.3 Dual token handling: JWT fast path versus opaque tokeninfo path

This is the centerpiece of the authentication wiring. The OnMessageReceived handler fires on every incoming request, before JwtBearer’s default validator runs. It looks at the token, decides whether it is a JWT or an opaque access token, and either steps out of the way (for JWTs, letting JwtBearer do its normal thing) or introspects the token at Google’s tokeninfo endpoint and constructs a ClaimsPrincipal manually.

Listing 3: OnMessageReceived — the dual JWT/opaque token handler

Walk through it from the top. The handler reads the Authorization header and bails out early if there is no Bearer token — there are other authentication schemes in ASP.NET Core, and an absent Bearer is not the same as a rejected one. Then it counts the dots in the token. A JWT is exactly three base64-url-encoded segments separated by two dots; an opaque Google access token is one long string with no dots. The two-dot test is the cheapest possible way to distinguish them and works in practice for every token Google currently issues.

If the token is a JWT, the handler returns and lets JwtBearer’s default validator run. That validator pulls Google’s public keys (JWKS) from https://www.googleapis.com/oauth2/v3/certs, verifies the RS256 signature, checks the issuer and audience, and produces a ClaimsPrincipal automatically. The downstream OnTokenValidated event then runs ValidateGoogleClaims to enforce the hosted-domain and verified-email rules.

If the token is opaque, the handler does the work itself. It HTTP-GETs the tokeninfo endpoint with the access token as a query parameter. Google responds with either a 200 and a JSON document of claims, or a 4xx that means the token is invalid. The handler treats anything other than 200 as a failure.

The audience re-check is the most easily missed part of this handler. Google’s tokeninfo endpoint validates the token — it confirms the signature is real and the token is not expired — but it does not validate the audience against your client ID. It will happily return claims for a token minted for a completely different OAuth client. Without the explicit aud comparison shown here, your server would accept tokens issued by any OAuth client at all, which means an attacker who controls a public OAuth app could mint tokens that pass authentication on your MCP server. The string equality check is the integrity boundary; treat it as load-bearing.

Once the audience is confirmed, the handler builds a ClaimsIdentity from the tokeninfo response, sets ctx.Principal so the rest of the pipeline sees the correct user, runs the same ValidateGoogleClaims function the JWT path uses, and calls ctx.Success() to short-circuit JwtBearer’s built-in validator (which would fail because the token is not a JWT).

Note: The HttpClient used for tokeninfo is a static readonly field at the top of the GoogleAuthExtensions class, not a per-request new HttpClient(). The latter is one of the most common bugs in .NET code: each new HttpClient opens its own socket pool, and under load the process exhausts ephemeral ports. The static instance is reused for the lifetime of the process and is fully thread-safe for GET requests.

5.4 ValidateGoogleClaims: hosted domain and email_verified

Both the JWT path and the opaque-token path eventually call into ValidateGoogleClaims. This is the function that turns "the token is real" into "the token belongs to a real Workspace user." Listing 4 shows it in full.

Listing 4: ValidateGoogleClaims

There are three checks, in order. The hd claim, when present, must match the configured hosted domain. The hd claim is only present on ID tokens (JWT); tokeninfo responses for opaque access tokens do not include it. Skipping the check when hd is absent avoids false rejections of access tokens; the email-suffix check on the next line is the actual security boundary that applies to both token types.

The email_verified claim must be exactly "true". A user can put any string in their email field at sign-up; only after Google has actually verified ownership does this claim flip. Without it, an attacker who controls a personal Google account could in principle list a corporate email there and have it appear in the email claim. Without an email_verified gate, that attacker passes your hosted-domain check trivially.

Finally the email itself must end in @shopsnap.com. This is the check that catches the most cases in practice: anything that does not unambiguously identify a member of your Workspace is rejected with a logged reason. The reason string is returned all the way up the stack and ends up in the structured log, which makes it easy to debug "why was Alice rejected?" without having to add ad-hoc logging.

5.5 Advertising the protected resource to MCP clients

MCP’s authentication discovery mechanism lets a client ask a server "what auth server should I send users to?" rather than baking the answer into the client’s config. The AddMcp call shown in Listing 5 publishes the metadata that drives this.

Listing 5: Protected-resource metadata for MCP clients

Resource is the canonical URL of this MCP server. AuthorizationServers points to Google. ScopesSupported is the minimum set the client should ask for. A compliant MCP client reading this metadata can construct the correct OAuth flow without any user-facing configuration beyond the server URL itself — the user types in https://mcp.shopsnap.com/api/mcp/v1, the client discovers Google, and the Google consent screen appears.

6. Wiring Authorization: Per-Tool ACL via Roster

Authentication only proves who is calling. Authorization decides whether this user is allowed to call this tool right now. Conflating the two is the most common cause of accidental data leaks in corporate APIs: "they had a valid token" is not the same as "they were entitled to that data." The codebase implements per-user-per-tool access control via three small pieces — an opt-in attribute, a custom AuthorizationHandler, and a JSON file on disk.

6.1 The opt-in attribute and policy registration

The attribute, shown in Listing 6, is twelve lines of code that exist only to make tool methods read better. [Authorize("ToolAccess")] would work just as well, but [ToolAccess] reads more naturally and centralizes the policy name.

Listing 6: ToolAccessAttribute

The attribute references a policy by name. The policy itself, the requirement it carries, and the handler that evaluates it are all registered in Program.cs as shown in Listing 7.

Listing 7: Policy and handler registration in Program.cs

ToolAccessRequirement is an empty marker class — ASP.NET Core’s authorization subsystem uses the requirement type as a discriminator to find the matching handler. The roster is registered as a singleton because it loads its data from disk once at startup and serves every subsequent lookup from an in-memory dictionary.

6.2 The handler and resource resolution

The handler is the busiest piece of authorization code in the project. It runs on every authenticated MCP request and has to figure out, from whatever object the MCP SDK passes as the policy’s Resource, which tool the user is trying to call. The MCP SDK passes different shapes for different request types, so the handler has to introspect them generically. Listing 8 shows the full file.

Listing 8: ToolAccessHandler

Read the handler from the top. Step one is to confirm that authentication actually produced a usable identity — if the user is anonymous or has no email claim, the handler logs and returns without calling Succeed, which the framework treats as a denial. Step two is to figure out what the request is asking to do, which is the ResolveResource method.

ResolveResource handles three shapes the MCP SDK can pass. RequestContext<ListToolsRequestParams> means the user is asking for the catalog of tools — there is no specific tool name to authorize, so the handler just verifies the user is on the roster at all. The per-tool filter pass that runs later will hide individual tools the user cannot call. RequestContext<CallToolRequestParams> means the user is actually invoking a tool — the tool name is on Params.Name. McpServerTool / IMcpServerPrimitive is the per-tool filter pass shape, used by the SDK when it needs to decide whether to advertise a tool in the listing.

Reflection is used here deliberately, in preference to taking a hard reference on the concrete SDK types. The MCP SDK is in active development and these types may move between versions; introspecting by name keeps the handler resilient. The cost is one GetType / GetProperty call per request, which at MCP volumes is not measurable.

6.3 The roster: loading, normalization, lookup

The roster is the source of truth for who is allowed to call what. It is a JSON file deployed alongside the binary, loaded once at startup, and queried on every tool invocation. Listing 9 shows the full implementation.

Listing 9: EmployeeToolAccessRoster

Three things in the roster are worth understanding. First, the constructor throws FileNotFoundException if the roster file is missing. This is intentional and important: a server that cannot load its access-control list should not start. Failing open — "oh, the file is missing, just allow everyone" — is the kind of bug that causes data breaches. Failing closed at startup means the operator finds out about a missing roster before any user ever does.

Second, the Normalize method strips every non-alphanumeric character and lowercases the result. The MCP SDK serializes tool names in snake_case at runtime, while the C# methods are PascalCase, and the roster file might have been hand-edited with either style. Normalization makes "GetRecordById", "get_record_by_id", and "get-record-by-id" all collapse to the same canonical key, so the lookup never fails for a typographic reason.

Third, the lookup is in-memory and case-insensitive on the email key. Email lookups happen on every authorized request — they have to be cheap. The dictionary is built once at startup; runtime cost is one hash plus one set lookup.

6.4 An example tool method

With the attribute, the policy, the handler, and the roster all in place, opting a tool into the access-control system is one line: stack [ToolAccess] alongside [McpServerTool]. Listing 10 shows what a typical tool method looks like.

Listing 10: A tool method opted into per-user authorization

That is the entire developer-facing API. Add the method, decorate it with [McpServerTool] so the MCP SDK registers it, decorate it with [ToolAccess] so the authorization handler gates it, and add the tool name to whichever roster entries should be allowed to call it. The cognitive overhead per tool is tiny, which matters: anything more burdensome would lead to developers forgetting and accidentally shipping unauthorized tools.

7. Audit Logging and Non-Repudiation

Authentication tells you who is calling. Authorization tells you whether they were allowed to. Auditing tells you, after the fact, that the call actually happened. The audit middleware shown in Listing 11 sits at the end of the request pipeline, runs after authentication and authorization have populated ctx.User, and writes one log line per MCP request with the user’s email and the tool name.

Listing 11: AuditLoggingMiddleware

Three implementation details matter. First, ordering: in Program.cs the middleware is registered after UseAuthentication and UseAuthorization, so by the time the audit middleware runs, ctx.User has been populated by the JWT pipeline. If the order were reversed, every audit line would say <anonymous>.

Second, request-body buffering. The MCP request body is read by the downstream MCP handler to dispatch the JSON-RPC call. If the audit middleware reads the body without calling EnableBuffering and then resetting Body.Position, the downstream handler finds an empty stream and the tool call silently fails. EnableBuffering is the ASP.NET Core idiom for "I want to read this stream more than once."

Third, what this gives you and what it does not. You get a per-request record of the form "alice@shopsnap.com called tool GetRecordById". That is enough to answer most after-the-fact questions: who pulled this report, who tried to access this tool. What this does not capture is the result of the call (success vs error), the latency, or the arguments. Adding any of those is straightforward but each adds risk: arguments may contain PII, and storing the result of a read tool may double the data-breach blast radius. Most teams ship the minimal version first and layer additional telemetry behind feature flags as needs become concrete.

Natural follow-ons to add later, in order of value:

·       Wrap _next(ctx) in a logging scope so downstream logs inherit the user identity

·       Capture the response status code (success vs framework-level failure)

·       Ship the audit stream to a write-once sink (e.g. Cloud Logging, S3 with object lock)

·       Add request and response latency for SLO tracking8. Defense in Depth

Authentication and authorization are necessary but not sufficient. A working corporate MCP server also needs the boring hygiene that turns a demo into a deployable system. This section covers HTTPS, secret management, SQL safety, transport choice, and the operational shape of the roster file.

8.1 HTTPS everywhere

Bearer tokens are sent in plaintext on the wire. Anything less than TLS makes them trivially stealable on any shared network, and "shared network" includes coffee shop wifi, hotel networks, and any infrastructure between the user and your server. The two-line excerpt in Listing 12 turns on HTTPS redirection and forwarded-headers support.

Listing 12: HTTPS and forwarded headers in Program.cs

UseForwardedHeaders is the piece teams forget. When the MCP server runs behind a reverse proxy or load balancer (as it should in production), the proxy terminates TLS and then forwards an HTTP request to your server with X-Forwarded-Proto: https as a header. UseForwardedHeaders teaches ASP.NET Core to honor that header, so RequireHttpsMetadata-style checks and the issuer URLs in token validation see the correct https:// scheme. Without it, the OAuth machinery may silently switch to http:// comparisons and fail intermittently.

8.2 Secret management

Secrets do not belong in source control. The repository uses a UserSecretsId in the csproj for development — the dotnet user-secrets tool stores them outside the project tree, in the user’s profile. In production, the same configuration keys should be served from a secrets manager (Azure Key Vault, AWS Secrets Manager, GCP Secret Manager) or from environment variables provisioned by your orchestrator.

The redacted appsettings.json shown in Listing 13 is what should be committed to the repository: real secret values are placeholders, and the actual secrets are sourced from the environment at runtime. Anything containing a real password or client secret should be in .gitignore and never reach a commit.

Listing 13: Redacted appsettings.json

8.3 SQL injection: parameterized queries by default

Every tool method in this codebase queries the database through Entity Framework Core. EF parameterizes every LINQ query automatically: a Where(r => r.RecordId == recordId) call generates a parameterized SQL statement with @p0 placeholders, never string concatenation. As long as you stay in LINQ, SQL injection is structurally impossible. The footgun to avoid is FromSqlRaw with string interpolation — prefer FromSqlInterpolated, which preserves parameterization, or stay in LINQ entirely.

8.4 Transport choice: streamable HTTP versus stdio

The MCP SDK supports multiple transports. stdio is the easiest to wire up for local development but offers no per-request authorization hook — the entire ASP.NET Core authentication and authorization pipeline is bypassed because there is no HTTP request. WithHttpTransport() is what makes everything in Sections 5, 6, and 7 work. If you need security beyond "the OS process boundary," HTTP is the transport that gives you the hooks to enforce it.

8.5 The roster as data

Listing 14 shows what a real-world deployable roster looks like. The file lives alongside the binary and is reloaded the next time the process restarts.

Listing 14: Sample employee-tool-access.json

Storing the ACL as a separate file (rather than baking it into code) means a roster change does not require a rebuild. In the project file the roster is marked as CopyToPublishDirectory=PreserveNewest, so it ships with the binary on every publish but can be updated independently in production. For larger deployments the next step is to put the roster in a database table or a directory service like Google Workspace groups, but a JSON file works well for the first few hundred users and is easy to audit by reading.

Note: TrustServerCertificate=True in the connection string is acceptable for an internal SQL Server with a private CA, but it disables certificate validation. In production, prefer a properly trusted certificate so the connection string can drop that flag and gain real transport-level integrity guarantees against the database.

9. Mapping the Pillars Back to the Code

The synthesis. Each row of Table 1 takes one of the pillars from Section 3 and names the file or method that implements it in this codebase. This is the table to keep open in another tab while reading the source.

Table 1: Pillars to implementation mapping

No single pillar is sufficient. An attacker who steals a token defeats Authentication but is still bounded by the roster (Authorization) and leaves a trail (Auditing). An insider who is on the roster bypasses Authorization for the tools they own but cannot reach the ones they do not, and every action they take is timestamped against their email. Defense in depth is what makes the failure of any one layer survivable.

10. Deployment Checklist and Hardening

Before opening the firewall, walk Table 2 top to bottom. Each item is something this article has covered, packaged for the operator who has to actually push the deploy button.

Table 2: Pre-deployment checklist

10.1 The full pipeline, end to end

Listing 15 is the complete Program.cs that ties everything in this article together. Every line corresponds to a section above: configuration loading, the database context, the Google authentication extension, the authorization policy, the MCP server registration, the middleware order, and the protected endpoint. Forty-eight lines of composition root for an entire corporate-grade MCP server.

Listing 15: Program.cs — the full pipeline

10.2 Where to go next

The architecture in this article is a solid foundation, not a finished destination. The natural next steps depend on scale. For a few hundred users one JSON roster is fine; past that, replacing the file with a Google Workspace group lookup or a database table is the obvious move. Per-tool authorization can be tightened to per-argument authorization — a tool that returns customer records can scope its results to the caller’s region or department by reading additional claims from the principal.

Fork the repository, point it at your own Google Workspace, ship a read-only roster first, and watch the audit log for a week before you add any write tools. The patterns above are the load-bearing pieces; everything else is product. Per-tenant rosters, fine-grained per-argument authorization, and shipping audit events to a SIEM are the natural follow-ons once the basics are running. Good luck, and ship safely.