Atlan + Immuta: Context-Aware Security for the Agentic Era
Live demos
Want to watch a live demo?
Atlan engineers bootstrap, test and deploy enterprise context on real data.
See it on your own data
Walk through how a context layer would work on your stack, with our team.
Talk to usAbout this session
Atlan creates the governed policy context. Immuta enforces the right access at the source. Watch the complete governed access flow live: from discovery in Atlan to dynamic provisioning by Immuta, and the same pattern extended to AI agents.
Speakers
Tim MarstonHead of EMEA PartnershipsAtlan · Host
Steven TouwCo-Founder & CTOImmuta
Razi ShafiqPartner Sales EngineeringAtlan
Full transcript8 chapters · searchable
Intro
0:00Tim Marston
0:00 Welcome to today's webinar. Whether you're here from morning time, afternoon time, or evening time, you are welcome here. My name is Tim Marston. I'm the director of partnerships for the EMEA region here at Atlan. I'm joined today by Steve Touw. Steve, would you like to say a couple of words to introduce yourself?
Steven Touw
0:19 Yeah. Great to meet everybody. Steve Touw, I'm co-founder and CTO at Immuta.
Tim Marston
0:23 And also Razi Shafiq. Razi, do you want to introduce yourself as well?
Razi Shafiq
0:27 Yeah. Great to be here. I'm Razi. I'm one of our partner sales engineers here at Atlan.
Tim Marston
0:34 Fantastic. Thank you, guys. So one of you has cued us through to the agenda already. Thank you. So we're gonna run through some material today explaining how Atlan and Immuta work together what it is about our integration that enables a, a tighter and more secure approach to agentic architectures, and we'll also have a live demonstration of the integration so you can see how that works in action.
The AI Context Gap
1:05Tim Marston
1:05 So the why we are here today we'll talk through first of all. And from an Atlan perspective, we're here to talk about context, and as you think about agentic and AI systems, as you move from experimentation to implementation and going into production, particularly at scale, there is often a barrier around context what we call the AI context gap as the reality of the outputs is not necessarily to the level of accuracy and standard and efficiency that you would desire or expect to be able to implement agentic architectures and AI at scale. Why this is, is because context is a complicated problem. It's not what...
1:52 When you query data as a human being, you already have an implicit understanding of a lot of the dimensions around that data that you're asking the questions of. But when you're trusting to a machine to ask those questions, you need to give it a lot of context to understand the dimensions and the background and the, and the context of the data that it is analyzing, so the answer it provides is accurate to the expectations of the user. So a very simple question like this, "Who are our top customers this quarter?" Is a very real-world example from, from one of the customers we work with.
2:27 Actually behind it, there's a lot of levels to that data that need explanation to the agent so that it is actually analyzing the right data, providing the right definitions against that data, and providing an answer that is truthful to the expectations of the user, and there's layers to that that require advice to the machine to be able to be accurate. And that context is not just one dimension of context. There, there is knowledge that needs to be shared with that agent.
2:58 So in, in the case of you know, understanding how data is used within the business, there's the expertise on how those seasonalities around a business might change or how the processes in the business have behaved previously, and there are the norms, you know, the rules and guardrails that an organization should follow in any given circumstance. And all of these three dimensions, knowledge, expertise, and norms, need to come together as context to provide that advice to the AI so that its results are both accurate and efficient.
3:37 And as you, therefore, are trying to apply that context to your agentic systems, the organizations that we work with, we see three common patterns of challenge with roll-out of agents and, and why Atlan is, is useful to them. The first is building and bootstrapping context for each individual agent. This is the, the first step typically an organization will go through when you're piloting your first agent inside an organization. You will probably do this yourself very manually. But as you start to build out multiple agents, going through a process of defining context and giving understanding to each agent individually becomes quite onerous. It's, it's a burden of effort.
4:17 And the context you provide may not stay current. It may age, and if you're not updating it, then the results will degrade over time that you get out of that, that process. Then the second barrier as you start to scale out is understanding how that data is changing. That recency of context, as I already mentioned, you know, becomes increasing burden. As the sort of flywheel turns and you scale out more systems, you know, it, it becomes more and more burden to maintain and manage those environments and those agents and their accuracy.
4:50 And then of course having that context being portable is really what you need to then automate at scale the provisioning and the allocation of resources to agents so that you can have a truly agentic architecture. So how Atlan solves this context problem is several layers of process that we provide.
How Atlan Solves the Context Gap
5:10Tim Marston
5:12 So first of all, we have a, an iceberg native layer for ingesting metadata and SQL query logs and, and related datasets, metadata sets into our platform. And in that metadata lakehouse, we then build on top of that graphs of knowledge of the data. And on top of that, we then build glossaries and ontologies. So you start to build out this multi-layered context. Then we provide a context engineering environment so you can define how that context is surfaced to your AI processes. We allow for a human in the loop to review and evaluate and approve, where necessary, those pieces of, of workflow.
5:55 But the intent is to provide as much automation as possible so that you are ready for scale with agents and AI And our proof point is the organizations that we work with. We have customers across most industry verticals. I think most... For me, the biggest sort of source of endorsement are the other software vendors who are in fact Atlan customers using Atlan as a, an acknowledged value add to their own systems and processes. And so as you look to implement Atlan into your environment it's important to understand that, that we're designed for interoperability. So, as I mentioned, we're bringing data into a lakehouse we call it metadata lakehouse or universal context lakehouse.
6:45 It's an Iceberg native layer that we're building this context on top of. But the way that surfaces out to your systems is most commonly through MCP at the moment, but we have a series of open approaches to sharing that context and surfacing it so that it can flow into your workflows as you wish. And the impact in the real world can be significant. Without context, you're expecting your agents and AI to straddle across potentially very large datasets without understanding, and even if the accuracy is good enough, the cost in token use could be substantial.
7:22 So what Atlan provides is both a reduction in token use as well as a higher level of accuracy in most circumstances, and we see a multiple in, in accuracy lift, so five to 10X. We see a three-quarters reduction in token use against query, like for like queries. And it allows for agents to be rolled out much more quickly with this confidence in accuracy and efficiency at the same time. But context alone is not the answer, and a good model alone is not the answer. For effective AI to be implemented, you need a good model. These are becoming rapidly commoditized through the different providers available in the market.
8:05 You need the context, as, as I've described, and why you need it I think is pretty clear. But you need to also have control, because control allows you to guarantee that the appropriate data is being used and surfaced in the appropriate places without any risk of leak or breach.
Immuta: Closing the AI Access Control Gap
8:23Tim Marston
8:23 And that is where Immuta comes into play, and I will hand over with that to Steve.
Steven Touw
8:31 Thank you, Tim. Yeah, so I'm going to walk through a few slides that explains Immuta and then a little bit of what Tim spoke about in terms of agentic access to data. And at the end here, bottom of the hour, we'll give a demo of all this. So this is Immuta at a glance. We have a way to do policy authoring and enforcement. So what that means is how do you control access to tables, columns, rows? You can build policies in natural language and have those pushed out to your data platforms. We also have request access request workflows which we'll talk a little bit about today in the demo.
9:17 And that is available natively in Atlan, where there's actually a button in Atlan where you can request access to data and fulfill that through Immuta immediately without any kind of administrator having to run a manual grant or anything. The agentic access permissioning, I'll spend a lot of time on that today. And then comply and recertification, understanding the, the outcomes of your decisions like being able to say things like who has access to PII data because of the rules that I've been building in Immuta or the access request workflows, or because agents have been querying data on behalf of humans. So this is all managed by our policy engine and audit as well. Okay.
9:59 So just like Tim showed I'll show the, the slew of customers. Some of the largest customers, highly regulated customers are Immuta customers, and of course, some of these are joint customers between us and Atlan. And as I mentioned, we're gonna spend a lot of time today in this, this middle layer in this webinar. So I'm gonna start with a little bit of a problem statement, and then we'll talk about a solution. Before agents and LLMs, when you managed access control at your database, it was limited to the folks that knew how to write SQL or your data engineers, the people that wrote BI dashboards.
10:40 So by nature of it being that small subset of users, you kinda got security for free 'cause the rest of the organization didn't have direct access to your database. But that changes in this AI world because anyone can come in here and ask a question of your data, and the agent can go, with the help of Atlan's context, go answer that question, right?
11:00 Which is why you need to start thinking about it's no longer this small subset of users that need accounts in your data platform that you need to manage, but there's a large set of basically everyone in your organization that might ever ask a question, which puts a lot more pressure on your data platform team and just, like, your cyber footprint in general. So Immuta, our hypothesis is that traditional security models were built for this dashboard area where you kind of already knew upfront everything that people were gonna query, and you could build rules around that.
11:37 But now when you have these AI agents turn every employee into an active data consumer, now the floodgates are open. Like, any kinda use case could be thrown upon you by a question someone asks. So this creates a huge scale tax where ticketing processes to give people access to data will never keep up, and so you're left with this stalemate of do I wanna innovate with AI or create security massive security footprint problems?
12:12 The a good way to think about this, this change, is this, this diagram, where on the left is where we see a lot of companies before they start using Immuta, which is, like a human comes in, they discover the data that they need. They might open a ServiceNow ticket someone reviews that and approves that, and then some admin in the data platform comes in and grants access, and then that human is finally able to run SQL on that data maybe, like, three days later on average. You know, we see customers where this takes weeks, in fact.
12:48 On the right is where we're going in terms of technology and what LLMs open us up to where the human doesn't even necessarily have to, like, discover the data first. They can just simply ask a question, and the Atlan context can discover the appropriate data to query, and the LLM can generate that SQL. And Immuta can actually informed of inform the agent of any access gaps. We could request those those gaps request access for those gaps i-immediately. Access is then to that agent, and the agent's able to run queries in a second.
13:26 So we go from like, from days to seconds in this world, and you need to have an architecture that supports this categorical change in how people are gonna want access to data. So kind of our controversial statement maybe, I don't know. Be interested to see how our attendees feel about this statement. But if you're waiting on a human to click approve in ServiceNow or manually create a role in SailPoint, your AI strategy is already broken. And this is what we're gonna demo these last two slides are what we're gonna basically show in this demo in a moment.
Agentic Security Patterns & Their Pitfalls
14:03Steven Touw
14:03 Before I get to the demo, though, I wanna talk a little bit about some AI, common AI security patterns and their pitfalls, what Immuta does, and how it works. So first thing to think about is in your, in your mental model of how you think about this, there's control plane security. So this is essentially like the front door. What, what agents can be called to do what actions and can they get into an application at all? And then you have the data plane where, okay, once they're in that front door and they start running SQL, what data does that agent actually see based on the user that's asking its its question?
14:46 And Immuta fits squarely in this data plane security. We do not solve this control plane security problem, but the best solution would include a control plane with a data plane security solution. So what do we see for this data plane, these data plane solutions across customers that... We've talked to tons of customers about this. We see some common approaches. One is this shared service account approach, where you have rules depending on the user that's coming in, that grabs an agent that essentially maps to a role, and that agent connects as a service account, and it runs as the agent's credentials to get the data or answer the question.
15:27 Archetype B, we see a lot of as well, which is when the human asks a question, the agent actually authenticates as the human, so as if they're the human. So all the policies that are in place for that human are also enforced on the agent. That's the second one we see. And then there's this just-in-time intent-based approach, which is in fact what Immuta does, and I'll talk more about that in a moment. But where the agent, before it connects to run the query, a policy engine is tasked with vending access on the fly that represents the user's access that's that's asking the question.
16:08 And that could be, like, scoped up and down based on the intent of what that user is doing. And this is a, a femoral role that's vended just in time to answer the question. So we'll talk a little bit more about that in a moment. So just to go through quickly some pros and cons. Archetype A, we see this a lot because it's simple to get started, but it's very coarse, and you end up with overprivileged situations where, like, the, these agents are actually giving people more access than they really need. You can't tell if the agent was running the query on behalf of a user, or the user was actually.
16:43 Or the agent was doing it themselves. Any time you need to add new permutations of access, like someone needs a slightly different sliver of access than is already provided by one of these agent roles, then you need to create a new role, and this creates a role explosion problem. And it's really incompatible with just in time, because you have to create these new rules and rol-roles every time there's new permutations of access. Archetype B, the impersonation one, seems like a great fit, right? Because, hey, if you already have policies for these users in your data platform, like, why not just authenticate as them?
17:18 But what this means is, remember my, my second or third slide, where you have to account for all those business users that might ask a question. That means you're gonna have to create an account for all those users in your data platform, just in case they might ask a question, which creates a cyber problem. The God mode risk as well, where some of these users are gonna be admins in that data platform. So if they go through the agent, and the agent authenticates as them, that means the agent has God mode privileges, and it could do bad things.
17:49 Similarly, you can't tell if the agent ran the query or the user, because it's, you know, they both looks, they both look like the user when the queries are being run. You're gonna have to set up complex OAuth configuration for every AI tool you have, and you have this kind of, like, all-knowing barrier where, where you have to perfectly predict every dataset users might ever ask a question about. So all of this is also very incompatible with the concept of just-in-time or intent-based access. Okay, and then just to hammer this home Sorry. And, and, and just to hammer home the just-in-time approach, which is what Immuta does this is actually true zero standing privileges.
18:31 You don't need to re-create accounts for all these business users up front. You can tell if the user ran the query versus the agent, if the user actually has an account in the data platform. The way you build policies in Immuta is much more scalable, ABAC approach. And it creates a separation of duties where you can build these policies in the policy engine, and that works for any AI use case, no matter how many new ones you build. And it lends itself to just-in-time intent-based access, 'cause we're vending this access on the fly based on policies.
19:02 But it does require an architectural shift where you're moving away from legacy static database role management to this policy-based automation. And Anthropic wrote an article or a white paper on zero trust for agents. I won't run through all these key points in it, but essentially there are security issues with archetype A and B. With A you can't tell who's running the queries, and you end up with this attribution gap, and it highlights with, with archetype B, the OAuth that, that God mode issue I brought up where, like, they can basically escalate, the agent can escalate his privileges and do bad things.
19:43 Whereas with this just-in-time approach, you get clear audit and you can do the just-in-time approach where based on intent of what the user's doing, you, you could scope the access up and down. And these are actually actual quotes from that article. So long story short, there are security benefits to this as well based on this Anthropic paper. So how does this actually work in Immuta? And this is what I'm about to demo in a moment here, where a human would come in and ask the agent a question.
Atlan + Immuta: Better Together
20:19Steven Touw
20:18 The agent wrapper would talk to the policy engine, in this case Immuta, and say, "Hey, you know, Tim's trying to ask me a question. Vend me a role that represents Tim's access as defined in Immuta." This deterministic role, rule will vend a role in the data platform that represents Tim's access. And so that query will be run with Tim's authorization by the agent account to limit Tim to only what he's allowed to see. And then once it's done, that role will be deleted from the system. So it's true just-in-time, zero standing privilege, access on the fly. Okay.
21:04 So how do we want to show how Atlan Immuta pulls this all together? So this is what I'm gonna demonstrate today. So we're gonna have a user come into Anthropic Claude, ask a question, and Claude is going to talk to Atlan to grab context in order to generate a query. And it's also gonna talk to Immuta to say, "Hey, this user is trying to ask a question. Vend me access for that user." So Immuta has some policies that were built by a governance user already that vends that access to the data platform, and then Claude connects to the data platform with that vended role, runs the SQL.
21:41 And in fact, that user will notice they don't have enough access and will request additional access. And on the fly, that policy will be updated, and Claude will rerun the query and see the newly available data. So how do I now share my screen, Tim? Do you need me to stop sharing?
Tim Marston
22:02 Ooh, that's a good question. Let me, let me stop sharing, and then you can take the helm.
Live Demo
22:09Steven Touw
22:10 All right, cool. Thank you, sir.
Tim Marston
22:14 You're very welcome.
Steven Touw
22:16 All right, so let me let Zoom get out of my way here. All right, so first thing I want to show is that agents are first-class identities in Immuta. And they can actually have attributes and groups. You use these attributes and groups to build ABAC policies. I'm not gonna spend too much time on how that works in this webinar. But we also have users. So we have this user, Uman. That's my terrible pun of that's the human user that's going to ask the question. And you can see Uman is in this customer order fulfillment team.
22:50 And we actually have a policy in Immuta that gives anyone in this customer order fulfillment team access to customer data. So Tim is has access to the. I'm sorry, Uman, not Tim. I'm gonna move on to my Uman example. So Uman has access to customer information, but the agent does not. And in fact, Uman doesn't even have an account in Snowflake. So I've left Immuta now, and I'm gonna run a query in Snowflake. And you can see that the Uman doesn't even exist in Snowflake. This will finish here in a second. I don't know why this is taking so long. All right, we'll come back to that.
23:40 I'll prove that in a moment. But there Oh, sorry. The, the Chat with Data agent has a Snowflake account. Okay, let's try a different one. Yeah, it looks like something's wrong here. All right, we'll come back to that. Let me refresh Snowflake and then... I don't know what's wrong with Snowflake. That's okay. We don't need Snowflake to do this. So we're gonna have Uman. So now I'm in Claude. And we're gonna have YouMan ask a question about customer orders.
24:28 And hopefully this works, 'cause if Snowflake's down, it's not gonna work. But so we're gonna ask this question about customer order. If you remember, YouMan has access to the customer data as defined in Immuta, but he does not have an account in Snowflake. So again, we're gonna kick this off, and the first thing it's going to do is it's gonna notice a tool that we have exposed that is going to search the Atlan context to build the query, and then ask for the vended role to run the query. So you can see we've got. This is what the response from Atlan when I asked this question about customer orders.
25:08 It found this data and recommended the query to run. So if we come into Atlan here, we can see that we've got this context engineering studio where we've we've, we've built all these details about these tables that we're querying as YouMan through the agent, and that's how Claude was able to generate the SQL from my very abstract business question. I don't know. Snowflake might be down. I don't know what's going on.
Tim Marston
25:48 Is that perennial problem, live demos.
Steven Touw
25:51 Yeah. I don't... So it's not able to actually run this query in Snowflake 'cause something's wrong with Snowflake. Oh, here we go. All right. So. All right, thankfully that resolved itself—... It looks like. So, so now we've. This ran the query via the, the Atlan context through that vended role. So we're actually able to see some answers to these question, my, my arbitrary question up here. So the other thing that is interesting here is it pointed out that customer name is redacted. So this is actually what I'm going to request access to in a moment once this thing finishes running.
26:34 Because, you know, as we spoke about earlier with the slides, the, the just-in-time permissioning allows you to scope access up and down on the fly based on potentially, like, different rules that you have in place for just-in-time access, which I'll show here in a moment. So customer name's redacted. I'm gonna come in here and say, "I need to see customer names. Can we please request a masking exception?" And I'm actually showing this through like the human actually clicking in the UI. So this is how you do access requests in Immuta. So I wanna see the customer name, but we could have had the agent do this over MCP directly to Immuta if we wanted to.
27:26 You can attach custom request forms for access requests. So in this request form, I'm actually asking the user for their intent for seeing this information in the clear. I'm gonna say it's break-glass fraud investigation. You can also have data use agreements that they have to agree to. And I'm gonna go ahead and submit this request. Okay, so what actually happened here. So YouMan requested this customer name access, and you can see the answers to their quest— to the, to the question was break-glass fraud investigation. And we actually had a rule in Immuta that said, "Hey, since your intent is break-glass fraud investigation, you're automatically given access for one hour."
28:07 So what's actually happening here is if we go back to our slides real quick the Immuta's actually updating that role that was vended at the database tier and giving it access to that column because that rule just got invoked. So we can go back to Claude and rerun this query because that, that access will be now, be there now. It was automatically approved. Can we please rerun that query? Okay.
28:51 So Immuta pushed that policy out to Snowflake, as I mentioned, and it's rerun this query. And what we'll see in a moment here is that the we're able to see those customer names in the clear now. So pretty cool. We did a. We were, we were able to have Atlan generate the query. The query ran in Snowflake with the vended access on the fly. The user realized something was missing, requested access. It was automatically approved through additional rules in Immuta, and now they see by rerunning that query, they see that, that new information in the clear. But remember, they're only gonna have access to that temporarily.
29:41 Okay, so let's see if we got Snowflake working again. If not, that's okay. We can skip this part. Aha. Let's see. Maybe, maybe we're back in business. Okay, so what you can also do is I can look at the Snowflake query history maybe and this will show me... Here we go. Good. So this is the query that we just ran, and you can see it was run with this chat with data agent. That's the agent that's connecting.
30:16 But more critically, as I mentioned, it connected with a role that was vended, and the role that was vended for that particular query ends in three two nine So what you can actually do is you can go into Immuta, and let's go back to our agent here. And we can see that this query that was... Or this role that was vended for You Man ends in three two nine. So we know that this query in Snowflake was actually done as an agent on behalf of You Man. So you're able to k-complete that circle. Okay.
30:59 Now, one last thing I wanted to show is what if You Man kinda already knows what he needs access to, and he didn't wanna, like, rely on the agent to to do that? So this is what I mentioned earlier, where you can go into Atlan and you can discover data that is important to you. And if you have the Immuta Atlan app installed this button will appear to request access. So similar to what we saw through the agentic workflow in Claude, you can do the same thing as a human logged into Atlan.
31:34 So if we click this Request Access button, similarly we have a request form set up that the person would fill out to get access. And in fact, I believe this one requires a manual approval, but we could say something like, "I need this for my project." And just to show you that this is completely customizable, these request forms, I put this silly question in here, and I agree to the data use agreement, and I can submit this request. And in this case, it's not actually automatically approved. You can see there's some separate reviewers that needs to look— that need to look at this and, and approve it.
32:11 So you can do a mix of automatic approvals with rules, or you can have you know, humans in the loop that need to approve access to potentially highly sensitive data or things that you don't have these kind of on-the-fly rules set up for, for approvals. So with that, that is the end of the demonstration.
QnA
32:33Steven Touw
32:36 I saw a lot of chats coming through. I don't know if there's some questions you guys wanna jump in and start answering or if I should start doing that. Or it looks like you've already— Razi's been jumping on, on most of them, I think.
Tim Marston
32:46 There's— Yeah... There's one outstanding, I think, for connecting to Aurora Postgres, I think. Razi, do you want to provide an Atlan commentary to that?
Razi Shafiq
33:01 Yep.
Steven Touw
33:03 Yeah. Do they... Do you... I assume they mean Atlan— I think they mean in the context of Atlan, but maybe worth.
Tim Marston
33:11 It was Smit who's, who asked. Smit Patel.
Steven Touw
33:16 Yeah, Smit at least from the Immuta side we support that, but not this agentic flow yet. That is on our roadmap, but it will be there by the end of the year.
Tim Marston
33:29 And from, from an Atlan perspective, I don't think we have a connector specifically for Aurora. But we do have a Postgres connector already built. I'm sure Aurora is not a, not a big stretch beyond that. Razi, were there any other questions that came to the panel?
Razi Shafiq
33:50 Two other questions that have come up. One, if we already have a data catalog, does this need to be fully replaced with this?
Tim Marston
34:03 Okay. Yeah, let's, let's start, start with that one then. Okay. So from, from an Atlan perspective, Atlan's heritage is, as was being a, a data catalog, but that's not really the core value that we're offering to our customers now. Now we're, we are primarily focused on this context layer for AI. And so we often now with our customers we expect them to already have a catalog somewhere probably. And we sit side by side with that, and we provide our capability for the AI layer. So it, it does not require the replacement of an existing data catalog if one is there.
34:46 Steve, from the Immuta side, how do you guys relate to, to data catalogs, and do you require changes to be made for the Immuta part to operate? You're on mute.
Steven Touw
34:59 Sorry. Yeah. For that request workflow I showed at the end, that button, you can make that work in any catalog. That being said, for the agentic workflow that I just showed with the context it's very important that that context layer works well, or otherwise your questions will not get answered well. So I think what Atlan has is a very good way of doing that. So I think, like, when you, when you evaluate your catalog, you need to think about, like, can it do the end MCP context vending? I'm speaking for Atlan here, but maybe you don't want me to. But like—...
35:41 I, yeah, I, I think you just need to be careful that, like, a catalog is a lot more than a catalog now. It's, it's, it's being able to, to send context to agents so they can generate SQL. So I think you just need to consider that in your, in your whole solution.
Tim Marston
35:57 Yeah. Awesome. Thank you. Thank you, Steve. I think there was another question that Razi's already answered in the chat around pushing context to Databricks Genie which the answer is a, is a yes.
Razi Shafiq
36:11 There was another one that just came into the Q&A.
Tim Marston
36:14 Okay.
Razi Shafiq
36:15 Can we speak to how Atlan plus Immuta works with Databricks, specifically calling out Databricks Unity Catalog?
Steven Touw
36:24 Yeah.
Tim Marston
36:24 Sure...
Steven Touw
36:24 Looks like you answered the metric view thing. In terms of how that on-behalf-of workflow I I shared with the vending works We then, with Snowflake it's a role, with Databricks it's slightly different. It's, it's actually a group that we vend, and it's something new in Databricks called exclusive groups. So you're able to connect to Databricks as an exclusive group, which limits your access just to that, that group's access. So that's how it works with Databricks.
Tim Marston
36:54 Was there an Atlan response required to that question, Razi, as well?
Razi Shafiq
37:00 Ju-just like the workflow that we saw with Snowflake, in Atlan it's the same. On the Immuta side, Steve mentioned how it does it for Immuta.
Tim Marston
37:12 Perfect. All right. Any other questions? I can't see any. I think we've covered most. Just scrolling through here. Final, final call for questions from the audience. If you have anything you would like to ask us, now is the moment to ask it. If not, I will also... While we're talking, actually, I should be sharing a link to book a demo. Bear with me while I throw that up so you can scan this QR code if you would like to book a full demonstration of, of Atlan for your environment. But if there are no other questions, then we can bring this bring this webinar to a conclusion.
38:02 Thank you, Steve, for so capably presenting Immuta and walking us through that integration. I think it's it's extremely powerful together, Atlan and Immuta, in, in an agentic workflow and as agentic architectures scale out. And I look forward to collaborating on many more customers in the months ahead. Thank you everybody for your time and attention. And hopefully we'll be talking to many of you separate to this in the near future. Enjoy the rest of your days.
Related videos
8 minAtlan + Immuta: the security context layer Context library · Video · 8 min
3 minAtlan + Cyera: compliance-aware agents Context library · Video · 3 min
8 minActivate 2025: AI Governance Activate 2025 · Session · 8 min
59 minWTF is the Context Layer? (EP 01) WTF is the Context Layer? · Live series · 59 min