enterprise data management

Design Your Identity Architecture Before You Design Your Data Models

Design your identity architecture before your data models.

3 min readInfoQ
Design Your Identity Architecture Before You Design Your Data Models

Identity architecture isn't an infrastructure detail you can delegate to a later sprint. As Vaishnavi Khosla argues, the way you design identities determines your data models, your service boundaries, and your revocation policies. This is an architectural first principle, not a governance afterthought. We agree, and we think most enterprises are still treating identity like a configuration file when they should be treating it like a foundation. The shift toward Autonomous AI agents need guardrails not just better code makes this even more urgent: if agents can browse, run code, and call tools, the identity layer underneath them must be explicit and bounded. You cannot bolt revocation onto a system that was never designed for it.

What makes Khosla's argument practical is that it forces a choice before you write a single schema. Graph-based identity models versus role-based access control is not a religious debate; it determines how you handle service accounts, how you integrate a vault you do not own, and how tightly you can bound revocation latency for an event stream. Most teams pick RBAC because it is familiar, then discover that service-to-service relationships in a distributed system do not map cleanly to static roles. A graph model, by contrast, reflects the real topology of permissions, but it introduces complexity in traversal and auditing. The right answer depends on your revocation requirements, and you will not know those until you define them up front.

This is where the conversation connects to broader infrastructure trends. When Dropbox deepens AI infrastructure with Tigris Data acquisition to support agent-native storage, they are implicitly betting that identity and data access will need to be co-designed. A storage platform for AI agents cannot assume a human in the loop for every permission check. Similarly, Box taps Nvidia AI to power content retrieval four times faster with fewer errors, but faster retrieval means nothing if the identity layer cannot enforce who sees what at that speed. Performance gains in AI-powered content retrieval will surface identity bottlenecks that were invisible at human scale.

The concrete takeaway is this: before you model your data, model who and what can act on it. Define your service account boundaries, your revocation latency tolerance, and your vault integration strategy as architectural decisions, not tickets in a backlog. The teams that do this will build systems that scale with agent workloads. The teams that skip it will spend the next two years retrofitting permissions into event streams that were never designed to carry them. That is not a governance problem. It is an architecture problem that governance cannot fix.

From InfoQ

The way you design your identities will drive your data models, your service scope, and your revocation policies; enterprise identity management is thus an architectural problem, not an afterthought. Based on our experience in service account governance, this article touches upon graph vs. RBAC, integrating a vault you don't own, and bounding revocation latency for an event stream.

Read the original at InfoQ