How to give an AI agent access to your game data without creating risk
min read
A human analyst with dashboard access opens a few reports, exports one CSV and goes to lunch. An AI agent with the same access can run hundreds of queries in minutes, reads every text field as a possible instruction, and sends what it finds to a model provider your team may never have assessed. Same login, different risk.
Access controls assume that the person using the access is the person who received it, and that this person can tell a question from a command. Agents break both assumptions.
When we built the GameAnalytics MCP server, we ran a privacy and security review before the build started. My position from that work, and some will disagree: the main risk is not the model. It is the access you give it.
Three problems that are new with agents
The inheritance problem
An agent uses every permission in the credential you hand it, without the judgment a person would apply. In 2025, researchers showed a coding agent connected to a Supabase database through a role that bypasses all row-level security.
It also works over time. When a producer leaves, you remove their dashboard access. Does the connection in their AI assistant stop at the same moment? Many teams have never tested this. Vendors get it wrong too: Asana found a flaw in its MCP server that made data from about 1,000 customers visible to other organisations. The access model was simply wrong.
The instruction problem
As Simon Willison put it,
"LLMs are unable to reliably distinguish the importance of instructions based on where they came from."
Invariant Labs showed what this means: a malicious issue in a public GitHub repository made a user's agent copy details from their private repositories, including a salary, into a public pull request.
Game data is full of text someone else wrote: player names, guild names, support tickets, store reviews, chat logs. Each is a place where an instruction can hide.
The residue problem
What an agent retrieves goes to the AI provider and stays in the chat history after you remove the user's access. You can cut the connection. You cannot recall the answer.
In 2023, Samsung banned generative AI tools for staff after engineers pasted source code into ChatGPT, because that data was hard to retrieve and delete. Agents do this automatically, one query at a time. For studios the stakes are higher, as player data can relate to children, which raises the risk under GDPR and COPPA.
Three principles to address them
Delegate, do not duplicate
The agent should act as the user, with the user's permissions and nothing more. No shared service accounts, no admin keys in a configuration file, and read-only by default.
Check access on every request, not once at login. The MCP specification says servers "MUST verify all inbound requests". In our case this is the control that matters most: when someone leaves an organisation, the next request from their agent fails, even if the connection still appears in their assistant.
Share answers, not records
Most team questions are about trends: DAU, cohort retention, revenue by country. None need a player ID. Give the agent aggregated results by default and treat player-level access as a separate project with its own review.
If the agent never holds player records, there is little to leak and less player-written text to hide instructions in.
Assume it will be fooled, and keep a record
Design as if a prompt injection will succeed one day. Limit what a fooled agent can do: no sending data out, no writing back. Then log every call, who made it, which tool, what outcome, but not the content, or your logs become a second copy of the data you wanted to protect.
What good practice looks like
Before you connect an agent to game data, check that:
- The agent uses the user's own permissions, nothing broader.
- Access is checked on every request, so removing a person removes their agent.
- It is read-only and limited to aggregated data unless you decided otherwise.
- Player-written text is treated as untrusted input.
- Every call is logged, without the data itself.
If a vendor cannot confirm these clearly, I would not connect it.
Where this goes next
My prediction: within 18 months, the first widely reported AI data incident in games will not come from a hacked server. It will come from an agent that had more access than it needed and followed an instruction hidden in text a player wrote.
The studios that avoid it will not have the best model. They will have decided early what their agents are allowed to see. At GameAnalytics, we made that decision before the first line of code. I recommend you make it before your first agent goes live.
