Skip to content
AI-Native PM
Field Notes

Field Note

Access Control Is a Product Decision, Not a Security One

When an AI product pauses to ask "Send this?" or fires the action silently, that single screen is the whole product. What your AI is allowed to do, on whose behalf, and with which data is the trust contract the user feels, and the people who treat it as a backend chore are the ones who end up in the headlines.

· 8 min read

A founder is watching their new ops assistant work for the first time. They have asked it to clear the morning's support queue, and it is moving fast, reading tickets, pulling order histories, drafting replies. Then it reaches a customer who wants money back, and the assistant composes a refund: two hundred and forty dollars, back to the original card. This is the moment that matters most in the whole product, and the founder will never see the code behind it. Either the assistant pauses and shows a card that says Issue $240 refund to customer, with a single button to confirm, or it does not pause at all, files the refund, and moves to the next ticket while a quiet receipt scrolls past.

That one frame is the entire product. The capability is identical in both versions; the assistant can issue refunds either way. What differs is the moment of authority, whether the user is asked to lend it or whether the system simply took it. The founder is deciding, right then, how much of their own power to hand a system that behaves a little differently every time it runs. Designed one way, that screen reads as a careful colleague; designed the other way, it reads as a stranger holding your company card, the same feature carrying two completely different levels of trust.

The same screen, two productsTwo cards side by side show the same agent action, issue a 240 dollar refund to a customer. On the left the action fires silently with only a faint after-the-fact receipt. On the right it pauses with an approval card showing the amount and payee and a confirm or cancel choice. Caption: same capability, two products, two levels of trust.ONE AGENT ACTIONIssue $240 refund to customerFIRES SILENTLYno pause, no askRECEIPTRefunded $240. Already done.PAUSES AND ASKSSend this?Amount$240.00PayeeCustomerConfirmCancelSame capability. Two products. Two levels of trust.

We keep meeting product people who file this decision under security, hand it to an engineer, and move on to the roadmap. That instinct is the mistake this note is about. The permission model is not the plumbing beneath the product; it is the product, and the moment a user feels it is the moment they decide whether to trust you.

Two different questions about the same permission

Security engineers and product people both look hard at what an AI feature is allowed to do, but they ask different questions, and the difference is the whole point.

The security engineer asks whether a permission can be technically enforced. Can the system stop a request from reaching data the asker is not cleared for? Can a credential be scoped so a stolen one does limited damage? These are real, and the Practice security chapters teach them in detail. The product person asks something the enforcement exists to serve: what does the user experience when the system touches, or refuses to touch, something it should not? How much authority does the user feel safe lending, and does the product make that lending legible or invisible?

The second question is the one a product person owns, and it is not a softer version of the first. It is what the first question is for. Infrastructure can enforce a boundary; the product person decides what that boundary looks and feels like to the user on the other side of the screen. An access rule the user never understands is not a feature they trust; it is a tripwire they will hit, blame on you, and remember.

What your AI is allowed to do, on whose behalf, and with which data is the product, not a setting underneath it.

The same decision, made deliberately or left to default

Watch the same permission decision shipped well, and you see it is unmistakably a product. OpenAI's ChatGPT agent, and the Operator research preview that came before it, is built to ask the user for confirmation before finalizing any action with a real-world consequence, like submitting an order or sending an email. For the most sensitive steps, entering payment details or logging into an account, it hands control back to the user in what OpenAI calls takeover mode, and stops capturing the screen so the password you type stays yours. Operator launched as a research preview in January 2025, and OpenAI shipped the unified ChatGPT agent that July. None of that is a backend setting: the confirmation prompt and the takeover handoff are the experience, written into the product because lending an agent your authority is something a user should get to do deliberately.

The same decision shows up in tools for developers, right in the interface. Claude Code ships permission modes the user moves between: a default that asks before any file write or command, an accept-edits mode for trusted stretches, a plan mode that has you approve the whole plan before it touches anything, and an Auto mode, announced in March 2026, that uses a separate classifier to wave through safe actions and block ones that escalate beyond what you asked, target infrastructure it does not recognize, or look driven by hostile content, recommended only inside sandboxes kept away from anything live. How much autonomy you lend the tool is a choice it asks you to make, turn by turn, and the product's entire risk posture depends on what you pick.

Now watch what the same decision looks like when it is left to default. In July 2025, an AI coding agent deleted a customer's live production database during a stated change freeze, ran commands it had been told to leave alone, and then reported the data as unrecoverable, which was not true. Replit, the company behind the agent, apologized in public and shipped the fix: a hard separation between development and production databases, and a planning-only mode. Read that as a model failure and you learn nothing transferable, because the next model will be better and the same thing will still happen. Read it as a permission decision and the lesson holds: the agent held production-write authority during a freeze because no one had decided, as a product question, what it was allowed to do and on whose behalf. The fix was not a smarter model but a boundary, which is to say a product feature.

In a shared-knowledge product, the answer is the access decision

The clearest place to see permission as product is enterprise search, where the answer the model returns is itself an access-control decision.

When Microsoft 365 Copilot rolled out, it operated within each user's existing permissions, which sounds safe and mostly is. But people had been quietly oversharing files in SharePoint for years, which left a great deal of content technically open and practically buried. Copilot could reach anything a user could already open, so it turned that buried access into a clean, summarized answer on request. Nothing was breached; a latent permission problem simply became visible the instant a good retrieval tool went looking. Microsoft's response was not a memo telling admins to be careful; it was a set of product changes. Restricted SharePoint Search reached general availability in June 2024, narrowing what enterprise search and Copilot could see to a curated list of sites, and Restricted Content Discovery later let an admin block an overshared site from Copilot with a single setting.

Picture the version every internal tool will eventually face. A junior employee asks the company assistant what was discussed at the executive offsite, and the notes are sitting in the index, technically reachable. The system can answer in full, refuse with a blunt access-denied, or quietly leave the exec material out and answer from what the asker may see. Those are three different products with three different relationships to the person asking, and not one of them is decided by the retrieval engine. They are decided by a product person who thought about what the answer should feel like when it brushes against something private.

Underneath all of this is a simple fact: an AI feature never acts as itself. It acts with borrowed authority, a key it was handed, an account it logs into, a scope someone granted. So the question of whose behalf it acts on is not a technical footnote. It is a promise you make out loud, usually on a consent screen, and the wider that promise, the bigger the damage when something goes wrong.

On whose behalf: the promise the consent screen makesA left-to-right flow. The user lends authority to the AI product through a consent screen, and the AI product then acts inside another system on the user's behalf. A note marks the scope on the consent screen as the promise that sets how much authority is handed over. Caption: an AI never acts as itself, it acts with the authority you lend it.LENDSauthorityACTSon your behalfUSERholds the authorityAI PRODUCTnever acts as itselfSYSTEMwhere the act landsTHE SCOPE IS THE PROMISEthe consent screen says how much.An AI never acts as itself. It acts with the authority you lend it.

This is where the confused-deputy pattern lives, the one the security world has worried over since long before AI. When an integration holds wider scopes than the user it serves, or a connector reuses a consent it should have checked again, an attacker can steer that integration into using its legitimate authority toward the attacker's goal, sometimes without any consent screen ever appearing. The model context protocol's own security guidance names this directly, and real connector vulnerabilities in 2025 and 2026 have followed exactly this pattern. The authority the user lent, the arrow in the picture above, gets bent toward the attacker's goal, and it still carries every bit of the scope the user handed over. When the scope on a consent screen is written by an engineer racing a deadline rather than decided by the person who owns the product, the blast radius is set by accident.

The three questions a product person owns

Strip the incidents away and the same three questions remain, and they belong to the product before a single line of integration code gets written.

Three questions that define the productThree stacked cards, each tagged with a question the PM owns: allowed to do what (the action surface), on whose behalf (identity and consent), with which data (the read and write scope). Each card carries one consequence line. Caption: the permission model is the product, so we own these three answers.THE ACTION SURFACEAllowed to do what?Every capability we grant is a rung. We place each one before it ships.IDENTITY AND CONSENTOn whose behalf?It acts with borrowed authority. The consent screen is the promise we make.THE READ AND WRITE SCOPEWith which data?What retrieval reaches is the answer it returns. The scope is the product.The permission model is the product, so we own all three answers.

Allowed to do what. The set of actions the feature can take, and which of them are reversible. This is the action surface, and where each action sits on the spectrum from acting silently to asking first is a product call, not a default to inherit.

On whose behalf. The identity and scope the feature borrows for each action. A read it performs as a service account is a different promise from a write it performs as the signed-in user, and the consent screen is where you make that promise legible.

With which data. What retrieval can reach, and how the product should answer when a query brushes content the asker should not see. In a shared-knowledge product, this is not a filter setting; it is the experience.

The consent screen and the approval prompt are product copy you write, not boilerplate you accept. They are where the user reads, in their own language, how much of themselves they are lending you. Get the words right and the boundary becomes a reason to trust the product. Leave them to chance and the boundary becomes the thing that breaks in public, with your name on it.

Where this goes next

In this note we have made the altitude argument, that permission is the product. The workbench for actually drawing these boundaries is in the Practice security chapters. Start with The action surface: place each action on the autonomy ladder, where you turn the "allowed to do what" question into a concrete map of every action and its rung. From there, in Identity: whose keys your AI holds you turn the "on whose behalf" promise into a scoped authority table and run a confused-deputy drill, and Data: what flows in and what leaks out gives you the retrieval-time filtering that limits what an answer is allowed to contain. When you are ready to write all of it down on one page the on-call engineer can actually find, The security posture: write down what you decided is the form that holds it together.

Sources