AI agents open up new routes to enterprise data, and app-level permissions can't cover all of them. In this article, Cisco engineering leader Greg Laws walks through how policy-based access keeps data safe across systems, and why agent memory deserves the same rigor.
We've been working with Greg and the Cisco team on the data layer that makes this possible. Hasura DDN powers the Supergraph and gives PromptQL, our multiplayer AI workspace, the connectivity and context it runs on.
The goal is simple: make AI genuinely useful at enterprise scale without losing track of who's asking, what they're allowed to see, and who's accountable.
Think about the data at any company over a few dozen employees.
There's the CRM screen a seller uses every day. There's the copy in Snowflake that analytics and finance query. There's a nightly extract feeding a partner portal, an integration API three other apps call, a BI dashboard someone built two years ago, and a spreadsheet exported for a QBR and never deleted. Now add an AI agent that can reach several of those at once and remembers what it saw.
Same data. Seven doors. In most companies I've worked in, each door has its own lock, and a different team holds each key.
I've spent the last couple of years putting agentic AI in front of tens of thousands of sellers, and before that I spent years in healthcare, where a data access mistake ends up in front of a regulator. The lesson from both is the same. Application permissions were built for a world where the application was the only way in. That world is gone, and agents are about to make the gap a lot more complex.
Where application permissions break
A seller in the CRM can only see accounts in their territory. That rule lives in the CRM's sharing model, and the CRM team maintains it carefully. Then the same account table lands in Snowflake, where roles were designed for analysts and are coarse. Somebody grants a service account broad read access so a pipeline can run. A BI tool connects with that service account. Now anyone with the dashboard link sees every territory.
Nobody did anything reckless. Each team secured its own door by its own standards. The problem is that "sellers see their own territory" was never written down anywhere except inside one application. When the data left, the rule stayed behind.
Every new copy, API, or tool means someone re-implements the same intent in a different permission model, usually from memory and usually a little differently. In healthcare, every audit turned into proving that four different systems enforced the same rule. Usually they did. Proving it was the expensive part.
Write the rule once, next to the data
Policy-based access control flips the question. Instead of asking "what does this app let this user do," you ask "what does our policy say about this person, this data, and this situation." NIST laid out the idea more than a decade ago. What's new is that we finally have to do it, because the number of doors keeps growing.
Attributes over roles. Territory, segment, data classification, requester location (data sovereignty) the purpose of the request. Roles become one input among several instead of the whole answer.
Policy lives with the data. Snowflake's row access and masking policies are a good sign of where platforms are heading: they apply regardless of how the table is queried. The limit is that they only cover the doors that go through Snowflake. Not to mention, it still requires making sure users (and their AI Agents) are in the right roles in most implementations as opposed to interrogating the data itself and the facts of the request for policy compliance.
One decision point every door calls. This is the part most companies skip. If the CRM, the warehouse, the APIs, and the agents all ask the same policy the same question, you get one answer. If each keeps its own copy of the rule, you get drift.
At Cisco, we built an agent data access pattern around this idea, with support from the Hasura team on the underlying data-delivery infrastructure. Agents that use it reach company data through the Supergraph, our GraphQL data delivery network built on Hasura DDN, the data-connectivity foundation that also powers PromptQL. Every request carries the identity of the user asking, or the agent acting on their behalf, along with metadata about them such as role, location, and hierarchy. The Supergraph applies that seller's entitlements, down to rows and fields, before anything comes back. The rules are defined once on the shared schema, so they hold no matter which agent is asking.
Cisco's team owns the business policies and the access pattern. Hasura's contribution is the data-delivery foundation and the engineering support that helped us put it into practice. That distinction matters: the policy is an organizational decision, but making it enforceable across access paths requires infrastructure, not just a better prompt.
The agent never holds data it shouldn't have. We don't ask it to behave. It can't see what the person asking can't see. Anything enforced inside a prompt is a suggestion.
That makes PromptQL relevant to the same architectural principle: put the user's identity and enforceable access rules in the data path, not in a prompt asking the model to behave. It does not mean every authorization integration is automatically enabled, or that memory governance is solved. Those are separate controls that still need to be designed and verified.
Agents add a door. Memory adds a copy.
An AI agent is the most flexible access path we've ever built. It can call the CRM API, query the warehouse, and read a document store in one conversation. If each source enforces a slightly different version of the rule, the agent will find the gap without trying. It doesn't need to be malicious. It just asks the source that answers.
Then there's memory. The moment an agent remembers something between sessions, you've created a new data store: a renewal date, a pricing exception, a note about a support case. That store usually has no row policy, no masking, no classification, and no retention schedule. It's a copy of governed data living outside the governance. Before any agent gets long-term memory, I'd want three answers:
Whose memory is it? If a manager's agent remembers something from a territory the manager can see, and it later surfaces for someone who can't, you've leaked data through recall. Policy has to be checked again when memory is read, not just when it's written.
How long does it live?GDPR says personal data shouldn't be kept longer than its purpose requires. Your warehouse has a retention schedule. Your agent's memory probably doesn't.
Can you find it to delete it? As one privacy attorney put it this year, you can't honor a deletion request for data you didn't know the agent stored.
An agent will use whatever it can reach
The second problem gets less attention, and it worries me more.
Agents are goal oriented. Ask one to prep an account review and it will find the renewal date, the pipeline number, and the open escalations wherever it can. If the governed path returns them, great. If not, it keeps looking. It might find the number in its own memory from three weeks ago, or in a spreadsheet attached to an email last quarter. Then it presents that number with the same confidence as live data, because nothing in the answer says it's stale. People usually know when they're looking at an old deck. Agents don't, unless you build that in.
It gets worse when access changes. Move a field behind a stricter policy, or retire a source because its data was wrong, and the agent doesn't stop wanting the answer. It routes around the change, back to memory or to an attachment it indexed months ago. You fixed the door, and the agent climbed in through a window you forgot was open.
That makes this a decision-quality problem as much as a security one. A seller quotes an expired discount. A manager forecasts off last quarter's pipeline. None of it looks like a breach. It looks like a bad call, and it's much harder to trace back to the data that caused it.
Where I'd start
You don't fix this all at once. Pick your most sensitive data and follow it.
Map the doors for one dataset. List every way a person or system can read your customer table. That list is your real attack surface.
Write the rule down outside any application. "Sellers see their own territory" should be a policy with a named owner, not a checkbox inside a CRM.
Enforce at the data layer, and make agents act as the user. No shared service accounts with broad read access. The agent sees exactly what the person asking could see.
Make freshness part of the policy. Everything an agent retrieves should carry its source and an as-of time, and the answer should show both. Memory and attachments are hints, not answers.
Govern memory like any other data store. Tag it with source and classification, re-check policy on recall, give it a retention clock, and when you retire an access path, clear the memories that came from it.
The companies that get this right will say yes to AI faster, because security and legal won't need to review every new agent from scratch. The policy already travels with the data. The rest will keep adding doors and hoping the locks match.
Here's what surprised me when I went looking: there's still no standard for how long an agent should remember what it read, or what happens to that memory when the source changes. There are no standards I can find for structured memory tagging that solves this deterministically, everything relies on the AI not saving, purging, or ignoring things in its memory after a period of time. GDPR says personal data can't outlive its purpose and has to be corrected when it's wrong, but it wasn't written with agent memory in mind. NIST's new agent standards work starts with identity and authorization. OWASP's agentic Top 10 treats memory as an attack surface and says to expire unverified entries, but sets no retention periods. The Cloud Security Alliance's draft agentic controls list session retention as a gap. Everything else is vendor defaults, so every company is writing its own rules.
If you've put a retention clock on agent memory, what did you tie it to: the source data's retention, the user's session, or something else?
Views are my own.
Originally published as a LinkedIn article by Greg Laws on September 29, 2026. Original article here.
