The agent has no rights of its own, and that is the whole point.
Building runtime Agent capabilities into a Pega application raises one question every architect eventually asks: how do you stop an Agent from doing something it shouldn’t?
When you are building runtime Agent capabilities in your Pega applications, how do you make sure your agents do not run wild? The risks of using Agents within a well structured Pega Application are smaller than you might think.
Two restrictions make this possible.
- Tool Availability: the Agent can only use tools you’ve configured
An Agent can ONLY retrieve data and perform actions through the Tools you make available to that Agent.
If your Agent does not have a tool to write to the database, it will never be able to alter the content of the database, regardless of the instructions your users give it.
As a Solution Builder, you decide which tools an Agent has available. This is the first layer of defense. - Rights Inheritance: the Agent always acts as someone
An Agent within the Pega landscape ALWAYS acts on behalf of a user, respecting the RBAC and ABAC mechanisms.
In a Conversational Agent setup, this is the user who is initiating the conversation.
In a Step Agent setup, this is the user to whom this part of the workflow is assigned.
Tool Availability:
Agents can be provided with a wide range of Tools and additional Data Pages.
Nearly any type of functionality in Pega can be ‘wrapped’ in a tool, including connecting to Data Pages, other Agents, and Activities. It is also possible to connect to external Agents and Tools.
This means it is possible to create extremely powerful agents which have tools to retrieve any datapoint, interact with any internal and external system, start any case type, alter any datapoint.
But this is a design choice: you can also create agents with an extremely limited and focused purpose, or an agent that can only retrieve data from a wide range of systems to answer question from the user, but has no powers to make any alterations to those data sets.
As with anything you configure in Pega, you are in control at design time about what can happen at runtime. Agent configuration is no different.
Rights Inheritance
The second layer is the specific behavior at runtime, which depends on the rights your users have.
When an Agent is called, either as part of a Conversation through the Agent Widget, or as a Step Agent in a Case Workflow, the Agent inherits the current user’s access rights. This includes all RBAC and ABAC controls.
So if user A has no access to DataPage X, and an Agent acts on behalf of user A, the Agent will also not be able to access DataPage X, even though it has a Tool to retrieve data from that DataPage.
This is what makes the model elegant: you never provision separate access for your Agents. Existing user rights simply carry through. If you cannot do something or access some data, then neither can an agent that does work for you.
In the demo below, we will see that two users interacting with the same agent get different responses, because they have different user rights.
Additional considerations
Audit data
Because the agent works on your behalf and using your rights, when we look at the meta data stored when an agent performs work for you, we will also see that your user name is stored. So if we look at for example the history tab of a case, we will see your user name there, even if the process was performed through an agent that you instructed to do so.
If you have a need to capture that the work was done by an agent on the user’s behalf, you can configure an additional entry into the history table to capture this.
In the demo below, we will see that the user-inheritance holds true even if multiple levels of agents are involved. In this demo, you’ll see a user interacting with a conversational agent, which calls a Case processing agent, which contains an Agent Step.
Background processing
If an agent runs as part of an unattended process. It is still tied to a model user with an access group. In that setup, the inheritance of rights happens from that model user’s access group.
Where the boundary ends
What is good to consider when designing for this rights-inheritance, is that this inherited rights structure works within the Pega application domain. If your Agent uses e.g. an MCP connect or A2A to reach outside your application boundary, you need a separate plan for how that external system authenticates the request. RBAC and ABAC don’t travel with the call once it leaves Pega.
Conclusion
True agent safety is not achieved through prompt engineering; it is achieved through architectural constraints. By combining strict design-time tool configuration with runtime identity inheritance, Pega lets you build agents that can only do what they should do, efficiently.