AI Engineer Summit 2025
Balancing Innovation with Security & Safety
Read the talk
Securing AI Agents from the Shared Process to Production
An agent’s permissions must survive every task and tool call. Security evaluations, runtime enforcement and live monitoring make that requirement testable and enforceable.
From a talk by Don Bosco Durai
Before you start: Familiarity with LLM tool calls, service credentials and basic application access control will help you follow the architecture and examples.
Where does one component’s access end?
When an agent delegates work to a task or tool, what keeps each component within its own permissions? Don Bosco Durai approaches that question from data governance: he introduces himself as Privacera’s co-founder and CTO and a creator and PMC member of Apache Ranger. Ranger’s governance work extends into cloud services through integrations such as Amazon EMR, Google Cloud Dataproc and Azure HDInsight. The agent problem brings that concern about access into an application that can decide its own next steps.
The architecture starts with four moving parts:
| Component | Responsibility |
|---|---|
| Agent | Reasons, constructs a workflow and invokes tasks or tools |
| Task | Performs a specific action, possibly using an LLM, retrieval or tools |
| Tool | Calls functions that reach internet data, databases or service APIs |
| Memory | Supplies context shared among agents, tasks and tools |
An application can contain multiple agents, each with multiple tasks and tools. In the diagram, the agent, tasks and tools sit inside the pink VPC region, with connections to an LLM, RAG, an API and a database. Those connections identify the places where context leaves a component and where an action reaches another system.
Durai characterizes most agent frameworks at the time of the talk as running agents, tasks and tools in a single process. A database tool needs credentials; an API tool needs a token. If those credentials are available within the shared process, another tool can potentially access them. The service credentials in his example carry super-admin privileges. That is an overprivileged configuration, not an inherent property of service accounts, but it makes unintended access especially consequential.
The exposure extends beyond credentials. Prompts used by agents and tasks also reside in the process, where third-party libraries may access them. Calls to an inadequately secured LLM add another exploitation surface. Meanwhile, the agent chooses a workflow according to the task it receives, so the developer cannot simply enumerate one fixed sequence of operations. Shared access and nondeterministic workflow selection combine to create security behavior that is harder to anticipate than a predefined application path.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A working agent can still be undeployable
These architectural weaknesses produce several different kinds of failure. Missing access controls can expose sensitive or confidential information. An unreliable model can return an incorrect result, and a changed prompt can alter behavior even when the underlying application code remains intact. Security and trust therefore depend on more than whether the agent completes its intended task.
Governance adds a separate production barrier. Durai recounts a conversation that Tuesday with an unnamed customer he describes as one of the top three credit bureaus. The customer had built many agents but was struggling to put them into production. It treated an agent much like a human user: onboarding, training and regulatory obligations had to be addressed before access was granted.
In the customer’s example, California residents’ data could not be used for marketing without the relevant consent. European data and other regional requirements introduced further restrictions on who could access information. The marketing restriction is the customer’s stated requirement, rather than a universal description of California law. The engineering consequence is concrete: an agent must respect the permitted purpose and scope of data use, not merely demonstrate that it can retrieve the data. Without those controls, the customer could not release its agents.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Evaluation, enforcement and observability
No single control covers this entire problem. Durai organizes the work into three complementary layers, beginning with a release decision. Security and safety evaluations must supplement tests of response quality and hallucination. Their purpose is to produce a risk assessment that determines whether an agent can enter production. An externally supplied agent should pass the same gate as one developed internally.
Enforcement supplies the controls that evaluations test. If the implementation cannot reliably enforce a restriction, its evaluation should fail and prevent release. Observability then covers behavior that development and initial testing did not encounter.
| Layer | Operational question |
|---|---|
| Evaluation | Is the agent’s risk acceptable for deployment? |
| Enforcement | Are permissions and safety constraints applied during execution? |
| Observability | What is happening in real use, and when must someone respond? |
The layers depend on one another: testing establishes confidence in controls, while monitoring reveals where that confidence needs to be revisited.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Test permissions and failure behavior before release
Agent security evaluations can build on established software release practices. Test coverage checks whether important behavior has been exercised. Docker image scans and dependency scans identify vulnerabilities and CVEs. Durai describes remediating medium, high and critical risks before production, alongside penetration testing for vulnerabilities such as cross-site scripting. Agents still need those checks; their model-driven behavior adds further cases to test.
Start with use cases and ground truth that define a regression baseline. Then changing a prompt, library, framework or LLM becomes a testable change rather than an assumption that behavior will remain acceptable. Durai also calls for checks on third-party models for poisoning and vulnerabilities, and minimum vulnerability criteria for libraries. Prompt-injection tests should exercise the application’s blocking controls; protection cannot be assumed merely because an LLM is involved.
Data-leakage evaluations need to distinguish users who ask the same question but have different permissions. Consider an HR agent that retrieves salary and benefits information:
| Requester | Requested record | Expected permission |
|---|---|---|
| Employee | Their own salary and benefits | Allowed |
| Employee | Another employee’s salary and benefits | Denied |
| HR administrator | Another employee’s salary and benefits | Allowed only if their role permits it |
A successful answer is not sufficient evidence of correctness. The test must establish whether that requester was entitled to the answer. It should also probe whether a malicious user can exploit a loophole to obtain a record that ordinary use would deny.
Two further evaluation areas extend beyond reading data:
- Unauthorized actions: An agent that changes a system must act for the right person or persona. Tests need to cover permission to perform the change, not just permission to inspect its inputs.
- Runaway agents: A bad user prompt, a problematic task prompt or an inability to resolve the task can send an agent into a tight loop. Those failure scenarios belong in preproduction testing.
Together, vulnerability checks, leakage tests, action tests and loop tests inform the risk score used for release. Durai supplies the categories and the decision they support, but does not prescribe a numerical scoring formula.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Constrain both the agent and the person it represents
The risk score depends on the quality of runtime enforcement. With libraries potentially able to access shared process state, sensitive backend access calls for a zero-trust approach: a component’s presence inside the application is not enough reason to trust its request. Prompt-injection detection and moderation remain relevant, but Durai’s enterprise enforcement discussion concentrates on authentication and authorization.
A request travels from user to agent, from agent to task, and from task to tool before reaching a service API or database. Authentication establishes the identity behind that request and prevents impersonation. Authorization determines what the established identity may access or do. These are separate requirements; a correctly authenticated request can still ask for something forbidden.
There are also two permission scopes to preserve. The agent has its own role and must not exceed it. When it acts on behalf of a person, that person’s permissions must also constrain the operation. Delegation must not turn a restricted user into a privileged backend caller. An agent’s ability to connect to a database or API does not entitle the user to everything reachable through that connection.
Approvals provide another boundary. In a traditional leave-request workflow, a manager approves the request through a predefined process. Durai proposes that a separately designed approval agent could check requests and results automatically. Its authority would be bounded by thresholds: work within the allowed range can proceed automatically, while a request beyond that range brings a human into the loop. This is a proposed approval pattern, not a demonstrated implementation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Carry identity all the way to the operation
Authentication at the application entrance is insufficient. The user’s identity must travel through every task and tool call to the final data access or API operation. That last boundary needs enough context to apply the correct policy. Otherwise, a backend may see only a powerful service account and lose the distinction between the employee and the HR administrator.
A TypeScript expression of that boundary can keep the HR example explicit. Here, trusted authentication supplies userId and roles, and trusted agent configuration supplies agentPermissions. The tool checks both permission scopes before asking the store for a record:
typescript
type RequestContext = Readonly<{
userId: string;
roles: readonly string[];
agentPermissions: readonly string[];
}>;
type Benefits = Readonly<{
employeeId: string;
salary: number;
benefits: readonly string[];
}>;
interface BenefitsStore {
read(employeeId: string): Promise<Benefits>;
}
async function readBenefitsTool(
context: RequestContext,
employeeId: string,
store: BenefitsStore,
): Promise<Benefits> {
const agentAllowed =
context.agentPermissions.includes("benefits:read");
const userAllowed =
context.userId === employeeId ||
context.roles.includes("hr-admin");
if (!agentAllowed || !userAllowed) {
throw new Error("Forbidden");
}
return store.read(employeeId);
}
async function benefitsTask(
context: RequestContext,
employeeId: string,
store: BenefitsStore,
): Promise<Benefits> {
return readBenefitsTool(context, employeeId, store);
}
The task preserves identity; the tool applies policy where the read occurs. An employee asking for another employee’s record reaches the denial before store.read. This application check is meaningful only if the runtime also prevents components from bypassing the controlled access path. Passing a context object alone does not isolate libraries sharing a process.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Monitor behavior that testing did not anticipate
Release testing does not freeze an agent’s behavior. Models change rapidly, agent frameworks evolve and third-party libraries can start behaving differently. Traditional applications also need monitoring and vulnerability management, but the agent adds a changing interpretation of user intent to those existing concerns.
Even an unchanged deployment may encounter language that its tests never covered. A sunny-day test might ask to apply for leave using one familiar phrase, while a real employee expresses the same intent very differently. Monitoring must reveal how responses change with those inputs. It should also track personal and confidential information sent out, so an unexpected increase in exposure can trigger action.
At sufficient request volume, reviewing every interaction is impractical. Define failure metrics and an acceptable tolerance, then alert when the observed failure rate exceeds that tolerance. An increase may come from a misbehaving agent or from a malicious user trying to compromise the application. The alert identifies a need to investigate; the failure count alone does not establish the cause.
Durai then looks toward behavioral anomaly detection, using established user behavior analytics as the analogy. Instead of only counting known failures, such a system would assess whether an agent remains within accepted operating boundaries. He explicitly describes agent anomaly detection as short of the capability he envisions at the time of the talk. The intended outcome is a security process that supplies near-real-time evidence of how the agent is behaving in live use.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A production security process and an open-source invitation
Production readiness therefore extends beyond a one-time evaluation result. Risk assessment governs both deployment of an internally built agent and adoption of a third-party one. Guardrails, enforcement and a secure sandbox constrain execution after admission. Real-time or near-real-time observability then makes anomalies visible soon enough to adjust the system. Sandboxing matters particularly for the opening architecture: permission checks cannot provide the whole security boundary if untrusted components can reach around them.
Durai closes by naming PAIG, introduced in the recording as the newly open-sourced PAIG.ai safety and security solution. Security and compliance span more than one company can solve, so his invitation is to design partners and contributors who can help develop it. He invites interested readers to contact him by email or on LinkedIn. The practical ambition is to make agent security a shared engineering discipline, with controls and evidence that let useful agents reach production.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Source code, examples and contribution information for PAIG's GenAI security, safety and observability framework.
Overview of centralized authorization policies and access auditing across Hadoop services.
Further reading
An architecture for applying user-specific Ranger policies and retaining audit logs across temporary Dataproc clusters.
Practical guidance on least privilege, credential access and isolation of untrusted workloads.
- California Consumer Privacy Act FAQsDocumentation
California's consumer-facing explanation of privacy rights, including opting out of personal-information sale or sharing.
Read the complete timestamped transcript
- 0:00
[on-hold music] I'm Don Bosco Durai.
- 0:18
I'm the co-founder and CTO for Privacera. Uh, very recently, we open sourced our solution for safety and security for GenAI and AI agent. Um, I'm also the creator and PMC member of the open source project Apache Ranger.
- 0:32
Uh, it does, uh, data governance for big data. It's also used by most of the, uh, cloud providers like AWS, GCP, as well as, um, Azure. Uh, so today, I'll be mostly talking about how you can build a safe and reliable AI agent.
- 0:53
So before I get started, let's get some of the terminologies, uh, uh, standardized. Um, from my perspective, AI agents are autonomous assistants. Uh, they can do their own reasoning, they can come with their own workflow, and they can, uh, call task for doing some actions, or they can use tools to get, um, uh, make API calls.
- 1:12
So tasks are more specific actions. Uh, they may be able to use LLMs, or they may, uh, also call RAGs or, or tools. While tools are functions which can be used to get data from the internet.
- 1:28
Uh, if you have databases, it can go and get data from the database. If you have, uh, service APIs, it can call those things also. And memories are contacts which are shared between the, uh, agents, the task, and the tools.
- 1:48
To give a visual representation, um, there could be multiple agents, and a agent may have access to multiple task. There could be multiple tools, and as these tools can talk with APIs and DBs.
- 2:01
So one thing that you need to know out here is, um, most of the, the, uh, agent framework today, they are run as a single process. What that really means is the agent, the task, the tools, they are in the same process.
- 2:15
That means if the tool needs access to database, that would needs-- need to have the credentials. Uh, if they want to make API calls, it needs shared tokens. So those credentials are generally are service user credentials.
- 2:29
That means they are, have super admin privileges. And since they're all in the same process, uh, one tool can technically access some other credentials which is in the same process.
- 2:39
Similarly, [clears throat] if you have task or agents which has, uh, prompts, all the things that's running within the process, any third-party library, uh, they can also access it. So those sort of makes this entire environment a little bit unsecure, right?
- 2:53
So there's a little bit of a zero trust, uh, issue out here. Uh, the agents, the task, uh, they talk to LLMs. The-- If you don't have a secure LLM, then that is another [clears throat] area where these things can get exploited.
- 3:07
Um, if you take agent on its own, by definition it's autonomous. That means it will call their own, uh, make, make up their own workflow depending upon the task. [clears throat]
- 3:19
So, [clears throat] so that actually brings in another set of challenges which we call in the security is unknown unknown. So you really don't know, like, what the agent is gonna do.
- 3:28
So it's very non-deterministic. So because of this, the attack vectors in a typical agent is pretty high considering from some of the traditional software.
- 3:41
So what are the challenges because of this, right? So there are multiple challenges. So if you look from the security perspective, if the agent is not designed or implemented properly, that can lead to unauthorized access, uh, also data leakages of your sensitive information and confidential information.
- 4:00
Right? Safety trust is also another biggest challenge. Uh, if you are using models which are not reliable or if your environment is not safe enough, if someone goes and change the prompts, that can also give you wrong results.
- 4:15
Compliance and governance is an interesting thing. Most of us are so much busy even just getting the agents working, we're not even worried about a lot of the other things that are necessary for making your agent enterprise-ready.
- 4:27
So interestingly, I was just talking to one of our customer this Tuesday. They're one of the top three, um, credit bureau. So they built a lot of agents, but their biggest challenge right now is to take it to production.
- 4:39
For them, they consider a AI agent as similar as to a human user, and when they onboard a hu-human user, they go through a training, and they have a lot of regulations they need to adhere to, right?
- 4:51
They have data from California residents, so they-- they have to make sure anyone who's accessing, uh, California resident data, they should not be using for-- uh, if the user has not given consent, they should not be using it for marketing purpose.
- 5:03
They have international, so their Europe data. So who can access the data? There's regulations around it. And also there are a lot of regional regulations. So when they consider even a AI agent similar to a human, so they have a onboarding process, they have a training process, and they want to make sure the agents are also following
- 5:21
the regulations, right? So without that, they can't go into production. And we as AI engineers, we're still in the early stage, so this one of the things which is out of our radar right now.
- 5:33
So now how do we really address this thing, right? So those who are in security are, are associated with security or compliance, there's no silver bullet. Uh, the best way to do, have multiple layers of solutions.
- 5:46
So these are some of the things that I have in my mind. Like, so you can split it into three different, uh, layers. The first layer is what is the criteria to even put your agent into production?
- 5:58
Right? What are you need to do, right? Uh, we talk about evals, but most of them we're only talking about evals for how good your model is, how good your response is, it is hallucinating.
- 6:08
But you also need to have evals which are more security and safety, uh, focused. So we'll go through some of those things, but the, the goal of this eval out here is to come with a s-- risk score.
- 6:20
And depending upon the risk score, you can decide whether you can even promote this agent to the production. And the agent may not be necessarily you are writing it.
- 6:27
It could be a third-party agent, so it has to go to the same criterion.
- 6:31
The second is enforcement. Um, eval generally tells you how good is your agent built, and enforcement is the one who actually doing the enforcement or implementation. So you have to make sure you have a pretty strong implementation.
- 6:47
If your implementation is not good, your eval is going to fail. Essentially, you can't go to production. And third is observability. Uh, particularly in the, uh, world of agents it's a lot more important because there's so many variables involved out here.
- 7:01
Like, you cannot really catch all of them during development or initial testing. So you have to keep track of how-- what-- how it is used in real world and how you can react on it.
- 7:10
So I will go through some of those things in a little bit more detail.
- 7:15
So, uh, let's start with the evals itself.
- 7:19
Right? Um, if you look into traditional software development, uh, there is already a process. There is-- there are gating factors that tells you how you can promote your application into production, right?
- 7:33
So if you start with basic things like, uh, when you're writing your code, you have to make sure you have the right test coverage, right? When-- If you're building, uh, Docker containers, you have to do the vulnerability scanning.
- 7:47
If you're using third-party software, you need to make sure you're, you're scanning for CVEs. If you find high or medium risk or critical risk, you try to remediate that before you can go into production, right?
- 8:00
Uh, you do pen testing to make sure there's no cross-site, uh, scripting and other, um, vulnerabilities. The same thing applies for AI agents also, right? You need to come with the right use cases.
- 8:12
You need to make sure you have the, the right ground truth, so that when you are doing any changes, you're changing the prompt or you are, uh, bringing a new library, a new framework, a new LLM.
- 8:23
You want to make sure your baseline doesn't change,
- 8:28
right? Uh, if you are using third-party LLMs, make sure they are s-- uh, not poisoned. They are s-- uh, they have been also scanned for vulnerability. Uh, if you're using third-party libraries, which almost everyone is using it, make sure they also meet your minimum criteria for vulnerability, right?
- 8:46
And similarly to pen testing, uh, you should also do testing for your prompt injection. Make sure your, um, your, your application has the right controls so it can block them.
- 9:00
And most of the LLMs are already doing it, but not necessarily all LLMs are doing it.
- 9:06
The other e-eval is around, around data leakage. Uh, this also is pretty important, particularly in the enterprise world, because when you are building enterprises, you're building agents which does generally what a human would do, right?
- 9:19
If you're building a agent for HR, uh, that will certain functionality. If I am employee, I can request for, um, uh, to get my b-- uh, salary benefits. But I can't do the same-- I can't get for someone else.
- 9:35
But if I'm HR admin, there's a possibility I may be able to access someone else's salary benefit, right? How do you make sure your agent is not leaking data?
- 9:44
There's no malicious user who can exploit some of the loopholes you have. So you'd have to do these evals upfront before even you can put tho-- your agents in the production.
- 9:54
Uh, similar to data leakage is unauthorized actions. Um, most of the agents, even though, uh, are read-only, there are also now agents coming which are trying to change things.
- 10:03
They'll, they'll do some actions. How do you make sure those are also done by the right person or the right persona? And runaway agents, um, uh, those who are-- uh, work on agents already know, like the agents can go in a tight loop and for various different reasons.
- 10:20
It could be a bad user prompt or just the prompt for the task, or the agents are not-- cannot address those things. So you have to make sure you test for such scenarios before you put your agent into production.
- 10:33
So the goal of this is to come with a risk score at the end of the day, so that it gives a confidence that can you put this into production.
- 10:40
And the next one is gonna be around enforcement.
- 10:45
As I said, your risk score is gonna be depending on how good is the enforcement. And particularly in agents, um, you're working in almost like a zero trust environment, right?
- 10:54
Because you have libraries which can access anything, right? Uh, if you are accessing certain of your backend systems which have sensitive data, how do you make sure the wrong user is not a-accessing it?
- 11:07
So, uh, from the security control, there are a lot of other things which I'm not gonna talk today, like, uh, detecting prompt injections and moderation. But focusing on enterprise-level thing, uh, you have to make sure you have the right authentication authorization.
- 11:22
Uh, this is pretty important because when you look at the environment, when a user makes a request to agent, it goes to task and eventually goes to tools and makes a API call to a, a service or a database.
- 11:36
If you don't have a right authentication, someone can impersonate someone else and may be able to s-steal confidential or sensitive information. And the second is authorization. If you have the authentication done properly, then you have to make sure the access control is applied properly.
- 11:53
And this is also important because agents have their own roles, and as a agent, they can do certain things. So you have to make sure they are not going beyond what they're supposed to.
- 12:04
And at the same time, if you have agents which are trying to do something behalf of another user, then you have to make sure the, the user, the-- that person's role is enforced.
- 12:16
So if you're accessing the database, it shouldn't access anything which the user does not have permission to or making API calls. So, so that's why authentication, authorization are s- super important.
- 12:26
Without that, um, obviously there could be a lot of other issues.
- 12:31
Approvals is interesting because, um, in the traditional world, we only have workflows. Uh, if I request for, uh, uh, leave, my manager will approve it. It's already built into the system.
- 12:43
But in the case of agents, you don't need to have a human all the time. Y- your agents can do most of the things automatically, right? So does it-- if you do it, design it properly, you could have another agent which all it does is just, uh, uh, looks for approvals and making sure the results are right.
- 13:00
And you can also put thresholds, how much these agents can approve automatically. And you can put the proper guardrails to make sure if it goes above a certain, uh, limit, it can automatically get a human in the loop.
- 13:16
So, uh, just to reiterate this one [clears throat] because it's pretty important, is when it comes to authentication, authorization, it's not just about doing the authentication at the point of entry, at the-- where you're making a request.
- 13:30
It-- You have to make sure the user identity is propagated across everywhere. If you're making a-- calling a task, or the task is calling a tool, you have to make sure the user identity is passed on to the, the, to the last point where it's actually making a data access or making API calls.
- 13:47
And that point, you have to make sure you're able to enforce the right policies and access control.
- 13:54
And the third is, um, observability. [clears throat] So observability is pretty important in the agent world because, as I mentioned, the traditional software, once you build it, it's-- then it just works.
- 14:08
Uh, you just have to make sure it is, uh, there's no, um, new vulnerabilities coming in because of some library update or something like that. But in the world of agents, um, there are many different variables involved.
- 14:19
One is the models change very rapidly. Um, you're-- if you're using an agent framework, that is also keep evolving, right? You're using third-party library, that may be-- start behaving differently.
- 14:31
Um, the another important thing in an agent is it's very subjective to what the user is entering. Uh, you may have tested with a certain assumption, mostly sunny day scenario, or I want to apply for, uh, my leave.
- 14:45
But the end user may use entire different, um, uh, um, text to ask the same questions. How do your models gonna behave best? So you have to keep monitoring to see if the user inputs or anything that changes, how the responses are coming in.
- 15:02
And also to make sure how much PI data and other confidential data has been sent out, because if you see some anomaly, you have to be able to ready to, yeah, act upon it.
- 15:12
Um, the other thing is, obviously, you can't monitor each and every request, right? As the number of requests increases, it's just not possible. So you have to start, uh, putting, uh-- defining thresholds and metrics.
- 15:27
So what that really means is, uh, uh, to start calculating, uh, uh, counting how many failure rates are out there. Once you know you have a certain failure ra- rates which is within your, uh, tolerance is fine.
- 15:40
But if it, if it goes above that, you can automatically create an alert and look into it. And the failure rates could be because of, uh, misbehaving agent. It could be a malicious users trying to, um, um, compromise the system.
- 15:54
Then anomaly detection and, is another interesting thing. Uh, I don't think we are anywhere close to it yet. Uh, but it's very common in, uh, the regular traditional software in the security side.
- 16:05
There'll be always something like user behavior analytics, where they look at the user and see whether they are within the, um, uh, um, standard operating thing. With agents coming in, uh, there'll be more and more of anomaly detection, whether agent is behaving within the, [clears throat] uh, accepted boundaries.
- 16:26
And all those things will end up with a security pros-process that will give you near real time saying how good your agent is actually performing in life. So that gives you to-- a bit of a confidence.
- 16:41
So to recap, uh, as I said, there are three things. One is preempt you. How vulnerability are eval to make sure that you get the right risk score, which gives you the confidence whether you can promote the, uh, um, agent to production.
- 16:55
If you're using third-party agent, whether you can use it in your environment. Um, second is proactive enforcement. Uh, make sure you have the right guardrails, you have the right enforcement, you have the right sandbox so that you are able to run the agent in, in a secure way.
- 17:11
Um, make sure you have the right observability so that you know at real time or near real time how good your agent is performing, and if there are, uh, some anomalies, you can go and quickly fine-tune it.
- 17:25
So, um, just as I said, we open sourced our, um, uh, safety and security solutions. Um, it's called PAIG.ai. Uh, security and, and compliance is a pretty vast field.
- 17:36
I don't think any single company can do it. Uh, so we are looking for, uh, design partners and contributors who can help us in our journey. So if you're interested, please reach out to, uh, me at [REDACTED:email_address] or connect me in LinkedIn.
- 17:51
Thank you. [audience applauding] [upbeat music]