Plexara
What you will take away from this lesson
In 206 - Knowledge: from memory to insights, we covered how memory and the knowledge pipeline persist facts across users and sessions. That power is exactly why governance is the next lesson: once an AI workspace can remember things and write to a shared catalog, the question of who gets to do what stops being paperwork and becomes load-bearing.
The point of this lesson is not to cover every security feature in detail. It is to give a power user enough of the model that when a tool is missing from your list, or a call is refused, you know why. Governance in Plexara is not a policy document. It is a runtime check that runs before the tool does.
Learning Objectives
- 01Explain why governance in Plexara is enforced at the point of execution, not documented in a policy and hoped for.
- 02Describe a persona: a named role that determines which tools a caller can see and which connections those tools can reach.
- 03Name the default-deny posture: no persona means no tools, and every tool call has to pass an authorization check against the resolved persona before it runs.
- 04Identify the layered safeguards that stack on top of persona filtering: read-only pinning, bucket-prefix scoping, workflow gating, row limits, and timeouts.
- 05Understand the single audit log that ties every tool call back to a human user and the persona they acted under, so "who did what" has a real answer.
Where we are in the curriculum
If any term in this lesson feels unfamiliar, the 100 series is one click back. The 200 series assumes that mental model.
100 Series: the foundation
- 101What is a Large Language Model?Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.
- 102Tokens and your budgetSubscription-plan economics, session limits, and Plexara enrichment dedup.
- 103Context, compression, and memoryThe keep / compress / clear playbook and how memory carries across sessions.
- 104Frontier models, specialized models, and why enterprise AI uses bothThree knowledge sources (training, web search, tools). MCP as the exposure protocol.
- 105What is an AI agent?The think/call-tool/observe loop. Professor's knowledge, child's literalism.
- 110Is MCP just an API wrapper?MCP as an application layer. Spectrum from thin wrapper to full application server.
If a term in this lesson looks unfamiliar, back up to the 100 series. The 200 series assumes that mental model. Every row above is a direct link.
Governance runs at execution time, not at catalog time
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. 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.
What a persona actually determines
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.
What a persona actually determines
Tool visibility
The agent only sees tools the persona is allowed to call. An unauthorized tool is absent from the list, which is the single most effective defense against prompt-injection attacks that try to coax the model into invoking privileged capabilities. The model cannot be persuaded to call a tool it cannot see.
Connection reachability
Tools that accept a connection argument (for example, trino_query against a specific catalog) can be scoped so only some connections are reachable for this persona. A read-only analyst persona might see the warehouse catalog but not an administrative connection.
Write vs read
Write operations are typically restricted to administrative personas. Trino connections can be pinned to read-only at the platform layer, so even if an agent somehow attempts a write, the write is refused before reaching the database.
Knowledge pipeline roles
Capture and review of insights (the 206 pipeline) are themselves persona-gated. An analyst can capture insights; a knowledge steward or administrator approves them via apply_knowledge. Separation of duties is enforced at the tool level, not at the honor system.
Personas are configured by administrators. platform_info reports the resolved persona at the start of every session, so the agent and the user can both see which role is in effect.
Default-deny posture
It is tempting to build access control around a permissive default: "if nothing else applies, allow read-only." Plexara goes the other way.
Layered safeguards on top of persona filtering
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.
Safeguards that stack on top of persona filtering
Trino read-only pinning
Individual Trino connections can be pinned to read-only mode at the platform layer. Write statements against a pinned connection are refused before they reach the database, regardless of what the agent intended or what the user asked for. Even a misconfigured downstream system cannot be written to through a read-only pinned connection.
S3 bucket-prefix scoping
S3 access can be restricted to specific buckets or bucket prefixes. An agent with S3 access cannot browse outside the configured prefixes, which means credentials that are accidentally over-permissioned at the AWS level are still safe at the Plexara layer.
Workflow gating
The session gate that requires platform_info as the first call (covered in 202) is a workflow gate. Plexara can enforce similar orderings elsewhere: discovery tools before query tools, insight review before knowledge application, and so on. A misordered call is refused with a structured error that names the missing prerequisite.
Row limits and timeouts
Query tools carry default and maximum row limits and per-connection timeouts. These are not advisory suggestions; they are platform-level caps. A runaway query is bounded by the smaller of the persona's limit and the connection's limit, so the blast radius of any single call is finite.
Identity: the step before everything else
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.
The audit log: a single record with user identity attached
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.
Every tool call is logged with user identity attached
Authenticated user
The human user the session belongs to, via the identity provider. Not a service account; the actual person who initiated the session.
Resolved persona
The persona in effect for the session. If a user has more than one persona available and chose one explicitly, that choice is recorded.
Tool invoked and arguments
The tool name, the connection it ran against, and the arguments passed to it. Redaction rules can be applied to sensitive argument fields.
Outcome and duration
Success, refusal, or error. How long the call took. The kind of information that turns "the query seemed slow" into something investigable.
Database-level logs see a service account; the Plexara log sees the human. The combination of the two (platform log plus downstream database log) closes the loop on “who ran this query.”
What governance looks like when you are the user
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 call gets refused with a structured error, a query completes but returns fewer rows than expected because a row-limit cap kicked in.
Where this leads
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.
Key terms
Six 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.
Key Terms
- Persona
- A named role, assigned per user (or per API key), that determines which tools the caller can see and which connections those tools can reach. Resolved at the start of every session; reported in platform_info.
- Default-deny
- The posture that a missing, invalid, or unrecognized persona grants no access. Misconfiguration becomes an access refusal, not a permissive fallthrough.
- Connection
- A configured backend a tool can reach: a Trino catalog, a DataHub instance, an S3 bucket, or similar. Personas authorize tools against specific connections, not just tools in the abstract.
- Workflow gate
- A required ordering between tool calls enforced at the server. The platform_info-first gate is the best-known example; other gates can enforce discovery before query, review before apply, and similar.
- Audit log
- The single log that records every tool call with the authenticated user, the resolved persona, the tool and connection, the arguments, and the outcome. Plexara-side, not database-side, so the human identity is preserved.
- Identity providerIdP
- The system that authenticates the caller before persona resolution runs. Plexara integrates with enterprise IdPs via OIDC and OAuth 2.1 with PKCE, and supports managed API keys for automation.