Who can see it, and who acts

The request was small. It was easy to say yes without thinking. Someone on the logistics team wanted to look at the graph. Just the shipping part: the freezers and the routes, nothing fancy. So they were granted Viewer.

Viewer. The most careful role on the list. Read-only. Look but do not touch. It is the role you give someone when you do not want them to have much.

By that afternoon they could read every node in the model. Not the shipping part. The whole model. Employee nodes with a pay band attached. Supplier nodes with contract terms. Customer nodes with a churn score that somebody's whole quarter was built on. All of it. And not because the grant was set up wrong. There was nothing to set up wrong. The grant was never limited to a part of the graph. No such limit existed to grant.

A different building, a different yes. A regional manager gets a recommendation from the agent. She reads it, agrees, and clicks Approve. The action runs. It runs against a system she has never had rights on. In fact she was deliberately denied rights on it. She could not have touched it by hand on her best day. The audit trail records the action as legitimate, and it is not lying. It was legitimate.

Two people did their jobs correctly. Two holes opened anyway. The two are not the same mechanism. They are not even the same surface. But they have exactly the same shape, and once you see the shape you will not stop seeing it.

A grant is a sentence, and people only read half of it

Every grant, in any system, in any decade, is the same sentence. Somebody may do something to something. Subject, verb, object.

Look at where the attention goes. All of it goes to the verb. Read, write, share, delete, administer. That is the part with the good names. The part with a ladder. The part where a careful team spends a whole afternoon deciding whether this contractor is really an Editor or only a Reviewer. Fine grading. Four or five rungs. Real thought.

Now the object. What are they allowed to do it to? Here many systems have exactly one answer: the whole thing. The item. All of it.

So the ladder you spent the afternoon on was built on the verb. Nobody built a ladder on the object at all.

So "Reader" was never a small grant. It was a narrow verb over a total object. Read-only, yes. Read-little, no. Those two phrases sound like the same comfort, but only one of them is something your system can actually promise.

The rule underneath is not really about software. You can only protect at the level you can grant at. If the smallest object your system can name in a grant is the item, then the item is the smallest thing it can protect. Every promise you want to make about a part of it is a promise you make with your voice, not with the system. A line in a wiki. A word from a colleague who meant it. Good people, real intentions, no enforcement.

When the work runs itself, whose name is on it?

The second half starts from a plain, honest question.

A person clicks a button and the system does the work, so the system does the work as that person. Easy. Now take the person away. A schedule runs at 3am. A stream crosses a line somebody drew months ago. Something has to happen, and there is nobody there to be.

Every piece of automation on earth has to answer this, and there are only about three answers. It can borrow the caller's identity. That is clean, but it stops working the moment there is no caller. It can have its own identity, a name in the directory that is not a person. That is tidy, but now somebody has to govern it. Or it can carry the identity of whoever built it. It acts as its author, with its author's rights, whether the author is at their desk, on holiday, or left the company in March.

That third one is delegation. I want to be careful here, because the rest of this page will read like an attack on it, and it is not one. Delegation is normal. It is everywhere. A huge amount of automation you already trust works this way. It is often the safest of the three, because the author is a real, accountable person who understood what the thing was for. That is a feature. It is not a shortcut somebody took.

The trouble is not delegation. The trouble is delegation standing next to an approval gate.

Here is what an approval gate actually does. It asks one question: does a human agree with this? That is a judgment check, and a good one. It catches the agent being confidently wrong. It puts a person's eyes on a result. It does everything the last concept asked of it.

But look at what it does not ask. It never asks whether this person is allowed to do this. Nobody wrote that check, because that check was already made, once, long ago, against the creator. The creator's rights are what the action will run with, no matter who is looking at the screen tonight.

So the two questions sit right on top of each other, and they feel like one question. Someone with authority looked at this and said yes. Read that again. It has the word authority in it, and that word does not mean what you just took it to mean. The approver had the authority to hold an opinion. That is all the gate tested.

The approver supplies the judgment. The creator supplies the permissions. Two people, one action, and usually only one of them knows it happened.

Enough theory. Here is a role list of the kind you actually meet, a graph with a few nodes on it you would not want passed around, and a rule that says somebody has to approve.

The number that will not move is the point of the first half. You can spend a serious afternoon deciding between Contributor and Viewer for someone, and you have not changed what they can read by even one node. And in the second half, the only time the approver's rights and the running rights match is when the approver happens to be the creator. Even then, nothing was checked. It matched by chance.

What a role on a graph actually grants

Microsoft's own framing is that Graph uses the same workspace roles as other Microsoft Fabric items. This is a choice, not a mistake. The graph is an item, items have workspace roles, so the graph has workspace roles. Admin, Member, Contributor, Viewer. The permission tables in the documentation are built on those four and nothing else.

Now read across the row that matters. "View and read content of graph model" is Yes for all four. Yes for Admin, yes for Member, yes for Contributor, and yes for Viewer. That is not a leak in the table. That is the table saying exactly what it means: the read is on the model, and the model is the unit.

Now the careful way to say the next part, because there is a sloppy version going around. The sloppy version is "Fabric graph has no security," and it is false. Workspace roles are real security. Item-level sharing permissions are real security. OneLake governance and lineage sit underneath. What does not exist today is fine-grained control inside the graph: no node-level, no edge-level, no property-level, no label-based access control. The security page does not soften them or limit them. The concepts do not appear on it at all.

I would not want to build an argument on silence, so here is the sentence that makes this more than that. On the page about sharing a graph and managing its permissions, under "Underlying data access," Microsoft says support for column-level and row-level OneLake security is under development.

Under development. Not a gap you guessed at. This is the product team writing down what is not there yet, in the exact place you would look for it. Missing by schedule, not by design.

Two things before you file this away. First, how current this is, because you might reasonably assume that general availability quietly brought security along with it. It did not. The graph engine went generally available in June 2026, and the overview page, updated 26 June 2026, after GA, still describes the governance story as native OneLake governance, lineage tracking, and workspace role-based access control. The same three things. GA did not add graph-native security.

Second, sharing is real, and it is still item-level. Sharing a graph grants Read, Write, Execute, and Reshare. There is also a graph-specific "Run algorithms" permission in private preview, which tells you the permission surface is being actively built out. But notice what "Run algorithms" is scoped to. The item. A graph-shaped permission is not the same as a graph-scoped one.

So: workspace roles plus item-level sharing permissions. That is what you have. It is real, and it is not the fine-grained control most people assume when they hand somebody Viewer on a model with salaries in it.

Whose permissions run the action

The other half is documented even more plainly, and in a place vendors do not usually put things.

In an Important callout on the operations agent documentation, Microsoft writes that the agent operates with the delegated identity and permissions of its creator, and that when a recipient approves a recommendation, the agent runs the action on behalf of the creator, using the creator's permissions.

The actions page repeats it word for word. And the limitations page closes the gap you might have hoped was open, under "Permissions and access limitations": queries and actions use the creator's credentials, the creator receives the recommendation messages by default, and changing the recipient does not change the credentials used for queries and actions.

Read that last part slowly. You can route the recommendation to anybody you like. Routing it changes who decides. It does not change who runs.

That is the shape from the first half of this page with a product's name on it. The approver supplies the judgment. The creator supplies the permissions. In an org where the creator is a platform engineer with broad rights and the recipients are line managers with narrow ones, every approval those managers give runs at the creator's level. That has the shape of a privilege escalation.

So be exact about what this is and is not. It is a documented delegation behavior. It is not a vulnerability, it is not a bug, and nobody is hiding it. What the docs describe is one delegation behavior. They do not document a row-level alternative, or graph-level authorization, or a service principal option that would run actions as something other than the creator. That is the whole claim, and I am not going to stretch it further.

Credit where it is due, briefly, because it is truly unusual. This constraint shows up in three first-party documents, twice inside Important callouts and once in a dedicated limitations article. Microsoft wrote down something that makes its own product harder to sell. That is the opposite of marketing, and it is the reason you can plan around it at all.

The balancing case, and why the two halves must stay apart

Here is the part that keeps this page honest. It is also the part a fast reader will get wrong.

The Fabric data agent, Fabric's name for an AI agent grounded in your data, is a different surface with a different answer. Microsoft's claim here is direct: the Fabric data agent honors all user permissions to the data, including Row-Level Security (RLS) and Column-Level Security (CLS). That is their sentence, and I am quoting it rather than putting it in my own words, on purpose, because it is a strong claim and it should stand or fall as theirs.

The same documentation spells out a two-level permission requirement. A consumer needs Read on the ontology item, and Read on the underlying semantic model, lakehouse, or KQL database bound to the ontology. If they have less than the listed permission, queries fail or return empty results.

So do not merge the halves. Two surfaces, two answers. The reason they differ is not a mystery once you look at where the check happens. Reading a graph model item is reading an item, and the item is the unit of the grant, so the answer comes out item-shaped. Asking a data agent a question sends the work down into a semantic model, a lakehouse, or a KQL database, and those sources have carried row and column filters for years. The enforcement lives on the source. That is why one surface can honor RLS while the other has row and column security listed as under development. It is not a contradiction. It is two enforcement points with two different units of grant. The practical version: "can they see it" has a different answer depending on which door they walked through.

Status, with dates, because every line of this is moving. As of 15 July 2026: the graph engine is generally available, since June 2026. The data agent is generally available. The semantic model is generally available. The ontology item and the Fabric IQ workload are in preview, and pointing a data agent at a graph or an ontology is in preview. Every claim above was checked on that date. This is exactly the kind of page that goes out of date, so go and read the row and column security line yourself before you design around it.

The one trap

Do not read a control as the answer to a question it never asked.

That is both halves of this page in one line, and it is the only thing I would ask you to carry out of here. "Viewer" answers what may they do. It does not answer what may they do it to, and you supplied that half yourself, for free, out of the ordinary meaning of a small-sounding word. "Approve" answers does a human agree. It does not answer is this human allowed, and again you supplied the missing half, because everywhere else in your life those two arrive together.

Both times the control was honest. Both times the reader filled in a promise that was never on offer. So ask it of everything, in any system, this one included: what question does this control actually ask, and what question do I believe it asks? The gap between those two answers is where somebody, doing everything right, opens a hole.

Every control on this page governs one action at the one moment it runs. Next: Plan, where the decision that matters most gets exported to a spreadsheet and quietly stops being governed by anything at all.