Transcript
You all heard saw the Chalk Talk about Savings Access Gateway and the importance of doing runtime authorization for agentic transactions. This Chalk Talk is going to focus on a very specific scenario of when a human is talking to an interactive agent, the agent works on behalf of those human counterparts. How should you design? How should you think about an identity transaction especially for your on behalf of flows for your agents? Let us take a look at it. It all starts with a human. In this case, let us say that human is Sarah and Sarah wants to invoke her CRM agent to perform some transactions on an application like Salesforce. So, the first thing what Sarah has to do is to authenticate to an IDP. This could be an Okta, Enter ID and provide her valid credentials so that the system knows that she is an authorized user to even invoke that agent. Now, as Sarah authenticates, she gets a valid user token from the IDP. This user token is then further passed to a CRM agent in this case. The first thing what a CRM agent has to do is it is to take the user token and get its own on behalf of or workflow authorization token to be created. Now, how does it do that? It goes ahead and talks to a session broker or an on behalf of broker. This could be from IDPs, this could be from Savient, it does not matter, but what here is really happening is that the CRM agent has to perform a transaction, authenticate and authorize itself to perform the agentic transactions what Sarah originally asked for from this agent. So, the CRM agent is going to give and start what we call it as an on behalf of exchange process. So, in this particular case, the session or the on behalf of broker would give an OBO token to the CRM agent, very simple, very easy set of steps. The user is authenticating first itself passing on to this agent and the agent is now getting an OBO token on behalf of so that the agent can perform the transactions, very, very simple. As well as in this case, the agent also has a valid identity available to it. Now, once all this happens, the next step in this case is it gets passed to the Savients access gateway. The MCP interface is doing one very specific thing and that is making sure that all the tools which are available and allowed gets exposed, which means you will start seeing the CRM agent having access to read opportunities. It will start saying send opportunities details, but it will also not be seeing transactions which are denied as part of the policy. That is the first set of things what will happen when an CRM agent goes to Savient gateway and Savient gateway is understanding what kind of tools are even exposed to this CRM agent. Next, a very important step is the policy evaluation stage. In the policy evaluation stage, the first thing what Savients access gateway does is intent analysis. It understands what did Sarah originally asked for and how is it getting mapped to the various transactions and tool calls what the CRM agent is really trying to do. It also looks for things like is your agent a rogue or an orphan agent and looks for any policies which says that anytime if a rogue or an orphan agent is trying to perform an agentic transaction it should be blocked. It looks for such policies, it looks for any SOD conflicts and enforces all of that in real time and last but not the least it maintains a complete audit and log every particular transaction which is being done by this agent. All of this is now happening at an access gateway level and at this stage there could be two different kind of information being sent to Sarah in this particular case. It could be an explicit approval or it could be an implicit policy based approval. You can always ask the access gateway to ask for any kind of a human in the loop approval done by Sarah. So, for example, if you want the opportunity details to be sent, but you want Sarah to humanly authorize that or approve it you can do that. So, you can have two different types of policy conditions once you are coming from this particular checks. Further in the very end once the Savient gateway performs all these checks now the next step is to actually perform this transactions into Salesforce or your CRM system. In this particular case what would really happen is that as your transaction is performed by the CRM agent what we are looking at in this particular case is who is your actor? In this case your actor is going to be Sarah. Who did work on behalf of Sarah? So, in this case it is going to be CRM-agent whatever your agent IDs are ID 001. What was the action performed? So, in this case it would be read opportunity and write whatever that opportunity data was and then last but not the least what was the time at which this transaction was performed. So, friends this is what really happens when you perform an agentic transaction specially for interactive agents where a human initiates a transaction, initiates or tells an agent what to do. An agent translates that into a particular transaction sends that to an access gateway component from Savient, Savient understands what kind of transactions can be performed what tool calls are available does an intent analysis enforces your security policies before it makes its way into a downstream application like Salesforce and regardless to say anything and everything what you do in this everything gets audited everything gets locked. That is the beauty of Savient's access gateway. As you start designing as you start creating your agentic transaction it becomes imperative that you cannot rely on design time controls for your agents you have to have runtime controls and that is what access gateway offers to you. In my next Chalk Talk I will talk about autonomous agents specially in multi-agent scenarios and how Savient's access gateway will play a very important role in authorizing runtime decisions till then stay tuned.
