Bricklayer’s Agentic Policy Enforcement architecture connects runtime enforcement with the context, authority, and policy that govern how autonomous work gets done.
NVIDIA’s announcement of its Open Agent Safety Platform caught my attention because it puts independent enforcement at the center of the conversation about autonomous agents. As agents become more capable, the systems around them need to govern what they can actually do. That is a problem we’ve been working through at Bricklayer from the beginning, and it has shaped both our architecture and the policy enforcement capabilities we’re building now.
We build autonomous AI agents that actually do things. They access data. They use tools. They write to memory. They call external systems. They delegate work to other agents. And as we give those agents more autonomy, we keep coming back to a relatively simple question:
Who decides what an agent is actually allowed to do?
Our answer is that it can’t just be the agent. Governing how agents work has been part of our architectural thinking from the beginning. Our procedure-based approach served as the original policy layer, giving execution a deterministic structure instead of leaving every decision to the agent. That experience shaped the independent runtime policy enforcement architecture we began seeking patent protection for in 2025 and are implementing.
That question became the foundation of the patent family we’ve been building around policy engineering and runtime policy enforcement in autonomous systems. Following the allowance of our second U.S. patent application, we’re continuing to build out the architecture it describes. The application is awaiting issuance. Its allowed claims build on our first patent’s runtime enforcement foundation to address how autonomous agents interact, how organizational boundaries are maintained, and how policy controls workflow execution. A third patent application is pending, extending this work into policy engineering: translating organizational governance into policy that autonomous systems can evaluate and enforce at runtime.
Intelligence, Agency, and Authority Are Different Things
One of the lessons we’ve learned building autonomous agent teams is that intelligence, agency, and authority are three different things.
A model provides intelligence. It can reason about a problem and determine what should happen. An agent adds agency. It can take that reasoning and actually do something with it. But neither of those things necessarily gives the agent authority.
Imagine an incident-response agent determines that an IP address should be blocked. It may be completely correct. It may have all the evidence it needs. It may even have access to the firewall API. That still doesn’t necessarily mean it should be authorized to make the change.
Or imagine an agent has access to sensitive information as part of an investigation and decides that an external service would help analyze it. The fact that the agent can access the information and can invoke the service doesn’t mean those two permissions should automatically combine into permission to send that information outside the organization.
This is where checking whether an agent has access to a resource stops being enough.
We aren’t simply asking whether an identity has access to a resource anymore. We need to understand who is acting, what they are trying to do, what they are acting on, why they are doing it, what has already happened, and what policy applies at that exact point in the execution.
That was the foundation of our first patent.
The Foundation: Govern Every Action
Our first Agentic Policy Enforcement patent describes an independent runtime enforcement architecture for AI agent systems.
At the center of it is what we call the Runtime Enforcement Engine, or REE.
In the patented design, the REE is intended to intercept an attempted action before it executes, rather than asking an agent to enforce its own permissions. The design calls for evaluating the security attributes associated with the participating components, applying organizational policy and runtime context, and determining whether the action should proceed.
The important part is that this isn’t limited to an agent identity.
The patented architecture provides for structured security labels across the components that make up an agentic system, including agents, tools, data sources, and memory. Those labels can represent things such as identity, functional role, data sensitivity, and execution level.
Conceptually, every consequential action can become:
Actor → Action → Target → Context → Policy → Decision
And context matters.
The same agent accessing the same data using the same tool may be permitted in one situation and denied in another because the surrounding execution is different.
The patented design provides for maintaining context across the execution for exactly this reason. Enforcement events can be linked within a workflow, investigation, case, or procedure so that the decision being made now can take into account what has already happened.
That means authorization doesn’t have to be stateless.
What an agent is allowed to do next can depend on what has already happened.
For autonomous systems, I think that’s a fundamental distinction.
Governance Has to Travel With the Work
The second problem we encountered was that agentic work doesn’t stay in one place.
A task becomes five subtasks. One agent delegates something to another agent. That agent queries a data source and calls a tool. The results are written to memory. Another agent reads that memory, combines it with another source, creates something new, and makes another decision.
If governance exists only at the beginning of that process, we’ve lost control of the system.
So another important part of our first patent was propagation and inheritance.
Tasks and subtasks can inherit security context. Procedure-level labels can propagate through a workflow. Memory and system-generated artifacts can derive their security attributes from the agents and data sources that contributed to them. The specification even describes derived information retaining its labels through subsequent reads, writes, and transformations.
This matters because an AI agent creating something new shouldn’t magically erase the sensitivity of the information used to create it.
And handing work to another agent shouldn’t magically erase the context under which that work began.
Put simply: Governance has to travel with the work.
That becomes even more important when agents begin managing other agents.
Govern How Autonomous Systems Work Together
The USPTO has allowed our second patent application, which expands this architecture in a significant way. Our first patent established the foundation: is this action permitted in this context? That foundation already included propagation, inheritance, delegation, escalation, and routing. The second builds on it: how is this autonomous work permitted to proceed? Its allowed claims address inter-agent policy enforcement, organizational boundaries, and policy-directed workflow execution.
One of the major areas is agent-to-agent interaction.
Modern agentic systems are quickly evolving beyond:
Human → Agent → Tool
toward something that looks more like:
Human → Agent → Agent → Agent → Tools + Data + Systems
Agents delegate tasks. They escalate decisions. They request work from specialist agents. Those agents may invoke tools, access data, create new information, or delegate again.
The allowed claims directly address these interactions.
They address runtime interception of interactions between AI agents, including delegation, escalation, and subtask execution. Policy can be evaluated against the participating agents and the surrounding context before the interaction executes. Depending on that evaluation, the interaction can be allowed, modified, transformed, or denied, and the task or workflow itself can be restructured.
There is a simple principle behind this that I think will become increasingly important: delegation should transfer work. It should not automatically transfer authority. An agent with greater authority shouldn’t become a privilege-escalation mechanism simply because another agent can ask it to perform something. And an agent with less authority shouldn’t automatically inherit everything available to the agent that delegated the task. Authority needs to remain governed throughout the interaction.
Organizational Boundaries Don’t Disappear Because Agents Can Talk
Agentic work crosses departments, environments, tenants, customers, partners, and organizations. Agents already interact across organizational boundaries through APIs and services. The fact that two autonomous agents can communicate doesn’t mean they should be operating under the same authority.
Our second application addresses this explicitly through organizational identifiers and isolation constraints. Runtime policy can evaluate the security context and organizational identity of the components participating in an interaction and determine whether an action across those boundaries is permitted, restricted, modified, transformed, or audited.
This becomes especially important in shared agentic infrastructure. An enterprise may have thousands of agents operating across different business units. A service provider may operate agents on behalf of hundreds of customers. In either case, collaboration has to preserve the boundaries around each organization’s data, resources, and authority.
The infrastructure can be shared.
The authority cannot be assumed to be shared.
That boundary needs to be enforceable at runtime.
From Runtime Enforcement to Agentic Control
This is where I think the architecture becomes particularly interesting. A binary allow-or-deny decision is a limited way to govern an autonomous system. Suppose a task violates policy when executed by one agent but could legitimately be performed by another. A particular component may be unavailable in the current context, execution may need to wait until a condition changes, or a task may need to be broken apart so individual operations can execute within different policy boundaries.
Simply stopping the workflow may be safe, but it doesn’t get the work done.
The allowed claims extend policy enforcement into the execution of the workflow itself.
The claimed architecture can modify execution by rerouting a task to another agent, substituting a component, delaying execution, terminating execution, transforming a task, or restructuring, decomposing, augmenting, or recombining the task or workflow.
Any alternative must be independently authorized under the applicable policy, including the restrictions carried by the data and the context of the original task. Assigning work to another agent cannot erase those restrictions.
The USPTO examiner’s reasons for allowance identify these same distinctions. For inter-agent interactions, the examiner pointed to retrieving existing security labels and evaluating policy using those labels and contextual conditions. For organizational boundaries, the examiner identified security labels and organization identifiers associated with the participating components. For workflow execution, the examiner identified retrieving workflow policy and evaluating it with the workflow’s contextual conditions. These were specific distinctions the examiner drew against the closest prior art.
Policy is no longer simply deciding whether work can happen. Policy can govern how autonomous work executes.
An Opportunity to Build on the Open Agent Safety Platform
NVIDIA’s recent announcement of its Open Agent Safety Platform highlights an opportunity to connect our work. The architectures differ, but they share an important principle: the enforcement boundary needs to exist outside the agent.
NVIDIA’s platform combines OpenShell’s runtime controls with Sentry’s independent monitoring and enforcement on BlueField hardware. OpenShell’s scope includes sandboxing, controls over API operations, credential protection, policy verification, and integration with external governance services. That extensibility creates a concrete starting point for exploring how workflow context could inform enforcement across the broader platform.
What interests me most is how NVIDIA’s Open Agent Safety Platform and the architecture we’re building at Bricklayer could reinforce each other. Our work focuses on carrying the meaning and authority of an enterprise workflow through its execution: which organization the work belongs to, what security attributes the data carries, who delegated a task, what has already happened, and how policy governs the next step. Connecting that context with independent enforcement could make both approaches more useful.
An investigation agent creates a summary from a customer’s restricted incident data and delegates analysis to a specialist. The specialist is permitted to call an external analysis service, but the summary retains restrictions that prohibit sending that customer’s information outside the organization. In a combined design, workflow-aware policy could reject that request and identify an approved internal analysis path, with the platform independently enforcing the applicable controls.
That is the opportunity I see in bringing these architectures together: connecting workflow context and policy-directed execution with enforcement across the application, runtime, and infrastructure. We are implementing our enforcement architecture now, and this is a direction I’d like to explore with the teams building the Open Agent Safety Platform. The goal is to let enterprises delegate more useful work because authority remains explicit and enforceable as that work moves.
Bricklayer is also a member of NVIDIA Inception, NVIDIA’s program supporting AI startups.
The Agentic Control Plane Is Emerging
As agents become more capable, I believe we’re going to see a new layer of enterprise infrastructure emerge between autonomous intelligence and the systems it can affect. We think of it as an Agentic Control Plane. Its job is to enforce the authority defined by organizational policy.
Models will get better. Agents will become more capable. And the amount of work enterprises are willing to delegate to them will continue to grow. That makes the separation between intelligence, agency, and authority more important, not less.
Models provide intelligence. Agents provide agency. The control plane enforces authority.
Our first patent established the foundation for governing actions throughout an agentic workflow. The allowed claims in our second application expand that architecture to govern how autonomous systems work together, preserve organizational boundaries, and control how work executes.
We began seeking patent protection for this architecture because these are problems we need to solve as we expand the autonomy of our cybersecurity agents. Increasingly, they look like problems every autonomous agent platform will have to solve.
Trust can’t live inside the agent.
