Summary
AI enthusiasm tempts firms to rethink data access from scratch. That instinct leads to overcomplication, slow reports, and governance gaps that surface late. The better move is to strengthen the entitlements architecture already in place and treat agents as one more caller in the existing system.
The conventional view of agentic AI in asset management paints a simple picture. If internal users vibe-code their own agents, they expect those agents to work seamlessly and tailor themselves to individual workflows. Centralized management doesn’t seem to be in that picture. But managing data access is still critical within our industry.
The reality is clear. While the technology is new, the requirement to prevent unauthorized access to transactional activity or asset classes remains unchanged. For years, this has been the central consideration when implementing data platforms.
However, the nature of the questions being asked about data access is shifting. The chief concern is whether AI agents themselves will bypass traditional controls. CTOs and CEOs have historically focused on interactive access for users and programmatic access for APIs. Today, AI represents just one more thing on that security checklist.
New questions have emerged, particularly regarding the chain of custody. If the setup is too loose, agents can pass data to each other and eventually leak data outside their appropriate audience. These scenarios aren’t all that different from classic data security risks, such as pulling a spreadsheet into a shared drive or emailing a screenshot to a counterparty. Ultimately, the core governance challenge remains unchanged.
The more interesting and complicated concerns, however, lie in access rather than security. If AI agents are doing work on behalf of multiple users, you need to get a handle on how they access data, what permissions they should have, and whose permissions they inherit. Technology leaders have to resolve that governance question before anything goes into production.
Firms already have established models for structuring data entitlements. Two of the most common are role-based access controls (RBAC) and attribute-based access controls (ABAC). Some systems support one, some support the other, and different firms prefer different approaches.
RBAC: A person’s role determines what they can see. For example, a user has access to a defined set of funds because they’re an operations analyst on a specific team in Asia.
ABAC: A user’s attributes determine what they can see. A user with attributes for the operations group and for Asia would have the corresponding policies applied to them dynamically.
In some ways, these approaches are a matter of preference and prior history. When entitlements are well-designed, a portfolio manager (PM), a risk analyst, and a compliance officer each see the right data at the right level of detail based on job function and location, among other characteristics. Presentation and reporting follow from how the architecture resolves access. If a firm launches new vehicles or adds new teams, it expands the model to accommodate them.
However, AI is orthogonal to a firm’s data access policies. It doesn’t change either model. You started with a tech stack before AI, and now you have a tech stack with AI. What we’re seeing is that the entitlements and governance system in place have to account for it. Clients already know how to validate their access and views. Identity access management (IAM) is already complex enough without adding AI. A Microsoft study on IAM found that only 2% of more than 51,000 granted permissions are ever used, while 50% were considered high-risk.i Now they just have to extend that validation and figure out how it works with their AI mechanism as well.
AI comes with the shock of the new, and it triggers a common tendency to overcomplicate data access. Firms typically build out their entitlements over time, adding policies to cover new funds, portfolios, teams, and benchmarks. In the pre-AI world, the complexity was manageable. They could enforce policies correctly and maintain performance with scale.
But when firms extend those same entitlements to cover AI access, the additional load starts to show cracks and creates a huge spike in load on the tools that enforce data governance. Everything still controls access correctly, but the system slows to the point where the experience is unacceptable. The situation could leave them thinking they have to go back to the drawing board to handle newly deployed agents.
Testing also presents potential problems. It’s very common for testing to happen in the context of a user with no restrictions, so everything works fine. The moment you test in the field with actual users, you find out they can’t access everything they need with acceptable performance. The cost of testing under admin access is that you don’t know whether something works until users are already using it and complaining. The rework becomes costlier at that point.
Even before AI enters the picture, firms have to take on three first principles. The first two seem familiar. Data has to be clean and reliable. AI needs enough business context to reason well and give correct answers. But the third one gets the least consideration. The system architecture has to be able to provision entitlements correctly across every access surface.
It would be completely out of the question in any financial services application to give AI access to your entire database and let all users query it. The better approach is for the agent to use the entitlements of the user who asked the question. The agent itself has no entitlements at all.
Imagine a PM in a fund builds a reporting agent that displays the day’s P&L and shares it with peers. The governance question is immediate: the agent can’t expose one PM’s P&L to another or show firm-wide figures to someone who should only see their own book. Equally, a user who can see everything asks for firm-wide data, and the same agent returns firm-wide data.
What’s happening is that entitlements resolve at the moment of a request. You don’t spin up a separate agent instance with its own entitlements for each user. That would be unworkable. Instead, a single agent serves multiple users and inherits whatever access controls already govern the platform. Rather than giving agents their own roles or attributes, you embed and enforce access control, so they respect the roles and attributes of the person using them.
That way, the agent is one more caller in the existing entitlements system, subject to the same rules as every other programmatic interface. Today, that would apply to agents that retrieve data. As agents mature and firms start granting them the ability to change data, the same principle would extend to write access.
AI can also play a different part for firms whose governance configurations have grown unwieldy. First, AI can reason through data lineage, detect quality problems, and do this better than labor-intensive manual work. When two users see different values for the same data, the ability to reconstruct what happened, to trace which policies produced which result, is something AI handles well.
Second, the same capability applies to the patchwork of entitlements that build up over time. You can use AI to analyze your governance setup and rationalize it by identifying optimization opportunities, finding redundant policies, and surfacing unwieldy configurations. However, it’s not a magic solution. It requires deliberate application.
Well-architected, consolidated platforms already give you an edge for successful data access management. It’s harder with highly distributed, highly bifurcated setups where multiple point solutions are strung together, because the entitlements logic is scattered rather than visible in one place.
The best thing you can do right now is take inventory of existing data access approaches, review your policies to expose excessive granularity, and resist the urge to rebuild from scratch. We believe the architecture already in place is the foundation AI needs. Strengthening it is a better investment than replacing it.
Dmitry (Mitya) Miller
Dmitry (Mitya) Miller is the Managing Director, General Manager for Aquata, Arcesium’s comprehensive self-service data platform purpose built for the investment management industry. Mitya is responsible for overseeing all aspects of the Aquata business, including P&L ownership, customer base growth, customer delivery and engagement, and product roadmap.
Sources:
[1] Microsoft, 2024. https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/2024-State-of-Multicloud-Security-Risk-Report.pdf
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
