207 - Governance: personas, access, and audit

If any term in this lesson feels unfamiliar, the 100 series is one click back. The 200 series assumes that mental model.

Most data governance in the wild ends up as documentation: a wiki page, a policy document, a spreadsheet of who is supposed to have access to what. The documentation is often correct and frequently ignored. Plexara takes a different approach. Every tool call is checked at the moment the agent tries to run it, not when the catalog is assembled. The documentation is the runtime behavior.

Three things have to succeed for a tool call to execute. The caller has to authenticate. Their persona has to be resolved. The resolved persona has to be authorized to call that specific tool against that specific connection. Any of those three failing causes the call to be refused, and the refusal is logged. No persona check, no tool call.

A persona is a named role. The assignment of a persona to a user (or to an API key, for automation) is how Plexara translates identity into capability. The agent never sees raw user identities when deciding whether to call a tool. The agent sees a tool list that has already been filtered through the persona in effect.

Power users often wonder why their agent can call some tools but not others, or why a tool they saw in documentation is missing from the list. The persona is almost always the reason.

A persona names the connections it reaches, and that same list decides what shows up when you go looking. Search a catalog and you get the datasets, connections, and API endpoints your persona can actually reach; the ones behind a connection it does not reach are held back, and the result says how many. A list you can act on end to end is worth more than a complete one you have to guess your way through.

The count is the part that does the work. An agent handed a short result set with no explanation concludes the data does not exist and goes off to re-derive it from something else. A result that says "four more, behind connections your persona does not reach, ask your administrator" produces a different next move: the agent tells you what to ask for instead of quietly building a worse answer.

A permission model and a working one are different things. A persona can be internally consistent, pass every check, and still leave someone holding half a capability: allowed to find an answer and not to read it. Plexara looks for that shape directly and reports it with the fix attached.

It is tempting to build access control around a permissive default: "if nothing else applies, allow read-only." Plexara goes the other way, treating least privilege as the starting point.

Persona filtering is the first layer. Several other layers stack on top of it to narrow what any given tool call can actually do, even when the persona is authorized to call the tool at all. These are runtime caps, not optional suggestions.

The catalog is the one place in the portal where ordinary use includes writing: a table gets a better description, a tag gets defined, a glossary term gets retired. Those edits go through the same tools an agent would call, so they get the same treatment. Two things have to be true, and both are checked on the server no matter what the interface shows.

The safeguards above bound what a tool call can reach. This one bounds what a tool call can claim to have done. It is worth its own section because the failure it prevents is the kind nobody catches by reading the output.

Governance is only half useful if a refusal is indistinguishable from an outage. An agent that reads "request failed" has three plausible responses and no way to pick: retry the call, rewrite the arguments, or tell the user the platform is down. Two of those are wrong, and the wrong one wastes the user's time or misreports the state of the system.

So every failed tool call in Plexara reports the same shape. A stable code the agent can branch on. A category naming whose fault the failure is. A message describing the specific failure, and a hint naming the corrective action when there is one. The category is the field that changes agent behavior: it is the difference between fixing a typo in an argument and telling you that your persona does not carry a capability and who to ask about it.

Authorization only makes sense if the system knows who is asking. Plexara integrates with enterprise identity providers rather than maintaining its own user store, which keeps governance aligned with whatever access decisions the organization already makes in other systems.

Every tool call produces an audit record. The record is written by Plexara, not by the downstream database, which means it carries the human identity through. A typical database log sees a service account connecting from the platform; the Plexara log sees the actual user whose session produced the call.

The practical value of this shows up in investigations. 'Who ran this query at 2am Tuesday' is an answerable question at the Plexara layer. 'Which persona did they act under when they ran it' is answerable in the same log entry.

Governance is mostly invisible when it is working. The rare times it shows up are exactly the ones where the user needs to understand it: a tool is missing from the agent's list, a search result carries a count of what it held back, a call gets refused with a category naming why, a query completes but returns fewer rows than expected because a row-limit cap kicked in.

Governance is the last of the subsystem-level lessons. The remaining lessons in the 200 series cover the two MCP primitives the series has not yet dug into: reusable prompts and reference resources. Then 210 closes with a worked end-to-end example that brings everything together.

Ten terms cover the vocabulary of Plexara governance. Persona and default-deny are the two that show up in day-to-day conversations; the rest are the supporting mechanisms.