Building a Governed Agentic AI Workspace
A Reference Architecture for Identity, Tool Access, and Data Boundaries
Lessons from a KrisperTech deployment of Cloudflare OS
Disclosure: I am employed by Cloudflare. This article reflects my personal views and independent technical experimentation through KrisperTech.com. It is not an official Cloudflare publication, architecture, or product recommendation. The deployment described uses generally available Cloudflare services, the public Cloudflare OS open-source project, and public documentation.
Artificial intelligence security changes considerably once an AI system can do more than answer questions.
An agent that can retrieve information, invoke tools, create artifacts, or interact with external systems presents a different security problem from a traditional chatbot. The security discussion therefore needs to expand beyond the model itself.
Who can access the agent? What information can it retrieve? Which tools can it invoke? When should a human authorize an action? Where does information leave the environment? How do we monitor what happens without creating another repository of sensitive information?
Cloudflare OS is an open-source AI workspace designed around agents, applications, organizational context, and controlled access to external systems. Its security model includes a capability layer known as Gatekeepers, which mediate how agents and applications interact with external resources.[1][2]
To explore those ideas in practice, I built a personal evaluation deployment of Cloudflare OS through KrisperTech and secured it behind Cloudflare Access: https://os.krispertech.com/
The objective was not simply to deploy an AI workspace.
It was to test what happens when familiar cybersecurity principles - identity, least privilege, explicit authorization, trust boundaries, data minimization, observability, and controlled external access - are applied to an agentic AI environment.
The result is a small reference architecture for a much larger problem: How do we give AI agents enough capability to be useful without giving them more trust than their task requires?
The Reference Environment
The KrisperTech deployment provides an identity-authenticated AI workspace with three (3) purpose-built capabilities.
The first is documentation research, which retrieves bounded results from approved public documentation sources.
The second is diagram generation, which converts structured descriptions into editable architecture diagrams.
The third is public subdomain discovery, which retrieves historically observed hostnames from public Certificate Transparency-derived information. Certificate Transparency records provide public visibility into certificates issued for domains, making them useful as one source of externally observable hostname information.[9]
These capabilities represent three (3) distinct types of agent interaction: retrieving information, generating and externally sharing an artifact, and querying an external security-data source.
What matters most, however, is not what the capabilities do.
It is how the agent is allowed to use them.
Rather than giving the agent unrestricted access to external systems, each capability sits behind a narrowly defined integration boundary.
The sanitized architectural pattern is: Authenticated User → Identity-Protected AI Workspace → Explicit User Approval → Narrowly Scoped Capability → Private Integration Boundary → Authorized Source or Approved External Service → Structured Result
That separation became the foundation of the security model.
Identity Before Agent Capability
The first control is identity.
The workspace is placed behind an identity-aware access layer so that access policy is evaluated before an unauthenticated user reaches the application. Cloudflare Access supports this model by acting as an authentication and policy layer in front of self-hosted applications.[3]
But authentication is only the beginning.
The architecture deliberately treats three questions separately:
Who is permitted to enter the workspace?
Who is permitted to administer it?
Which agent action is the user authorizing at this moment?
Those are different trust decisions.
A user being authenticated should not automatically make that user an administrator. Likewise, authorization to interact with an AI workspace should not automatically authorize every action the AI might be capable of performing.
This leads to an important principle for agentic systems: Authentication establishes identity. It should not establish unlimited authority.
The distinction closely follows the broader Zero Trust principle that trust should not be granted implicitly because of network location, ownership, or prior access. NIST's Zero Trust Architecture similarly separates authentication and authorization decisions and focuses protection on individual resources rather than broad network boundaries.[7]
As AI systems gain the ability to act, that distinction becomes increasingly important.
Give Agents Capabilities, Not General Access
The next design decision was to keep each integration narrow.
The documentation capability searches documentation.
The diagram capability creates a defined type of visual artifact.
The public-hostname capability retrieves a specific class of public information.
None exists to provide the agent with unrestricted external connectivity.
This is essentially least privilege applied to an AI agent.
Instead of asking: What systems could this agent connect to?
the better question is: What exact capability does the agent require to accomplish this task?
OWASP describes excessive agency as a risk created by excessive functionality, excessive permissions, or excessive autonomy in LLM-based systems. Its guidance specifically recommends granular tools, minimum necessary permissions, and human approval for consequential actions.[8]
The same principle shaped this deployment.
A capability that searches approved documentation does not require arbitrary web access.
A capability that generates a diagram does not need access to unrelated organizational systems.
A capability that retrieves publicly observed hostnames does not need to become a vulnerability scanner.
Reducing tool scope reduces the number of assumptions we need to make about what the agent could eventually do with it.
Tool Invocation Is an Authorization Event
The deployment also does not assume that an AI agent should execute an external operation simply because the model determines that doing so would be useful.
Before one of the custom capabilities retrieves external information or creates an external artifact, the user is shown the proposed observation and asked to approve it (human-in-the-loop (HITL) approval).
The lifecycle becomes: User request → Agent identifies required capability → Proposed action is presented → User approves → Capability executes → Structured result returns
This does not mean that AI agents cannot automate tasks. It means that reasoning and authority are separate things.
An AI system can determine that an action would help accomplish a goal without automatically possessing authority to perform that action.
That becomes increasingly important as agent actions move from retrieval into operations that can modify systems, send information, create resources, or trigger downstream processes.
Human approval therefore is not simply a user-interface feature.
It can serve as an architectural trust boundary.
AI reasoning can recommend an action without automatically authorizing its execution.
Separate the Agent From Its Tools
The custom capabilities are deployed separately from the main workspace.
The workspace reaches them through private service boundaries rather than making each integration another API.
Cloudflare Workers service bindings support Worker-to-Worker communication without requiring the called Worker to be reachable through a publicly accessible URL.[4]
This creates an intentional separation between the workspace, the agent, the capability, the information source, and the external service.
That separation matters because each boundary becomes a place where controls can be applied independently.
Authorization can differ.
Input validation can differ.
Logging can differ.
Data-handling requirements can differ.
One capability can be changed or disabled without necessarily redesigning the entire agent workspace.
The capability itself can also remain much smaller than the general-purpose AI environment invoking it.
Agentic systems become easier to reason about when the agent is not simultaneously the tool, data source, policy engine, and external interface.
External Data Movement Should Be Visible
The diagram-generation capability provides a useful example.
The agent can create an editable visual artifact using an external sharing service. The artifact payload is protected before transmission, but an important fact remains: Information is leaving the controlled environment.
The resulting artifact therefore needs to be treated as externally shared information regardless of the protections applied while transporting or storing it.
That distinction matters.
Encryption can protect confidentiality, but it does not answer whether the information was appropriate to disclose to that destination in the first place.
For this reason, the evaluation environment is deliberately limited to non-sensitive information.
Confidential, regulated, customer-proprietary, or otherwise sensitive information is outside the intended use of the deployment.
The broader principle is: Encryption does not automatically make an external disclosure appropriate.
Organizations still need to understand what information is leaving, where it is going, why it needs to leave, who controls the destination, and what happens to the resulting artifact.
Agent interfaces should make those transitions visible rather than burying them inside tool execution.
Security Capabilities Need Boundaries Too
The public-hostname capability demonstrates the same design philosophy from another direction.
It retrieves historically observed hostnames associated with a domain using public Certificate Transparency-derived information.
It deliberately stops there.
The capability is not intended to prove that an observed hostname remains active or reachable, and it does not progress into active probing, authentication testing, port scanning, or vulnerability assessment.
That boundary is intentional.
The defined purpose is to retrieve public information that may help initiate an external attack-surface or asset-governance discussion.
Once that purpose has been satisfied, the capability stops.
An AI agent does not need progressively broader security capabilities simply because those capabilities are technically possible.
This is capability minimization in practice. The same principle applies far beyond security tooling.
Bounded Retrieval Matters
AI systems create a natural incentive to retrieve more information because more context may improve the model's answer.
That assumption deserves scrutiny.
The reference implementation deliberately bounds retrieval rather than returning unlimited information to the agent.
There are security, privacy, reliability, and operational reasons for doing so.
If an agent only needs a small amount of relevant information to complete a task, retrieving an entire dataset increases exposure without necessarily improving the outcome.
This leads to another useful principle: Do not confuse maximum context with minimum necessary access.
AI systems benefit from context. Security architecture should still determine how much context is actually needed.
Model Governance Is Only One Layer
The deployment also places an AI gateway in the model path.
AI Gateway provides a control and observability layer for AI applications, including capabilities such as analytics, logging, routing, caching, rate controls, and model fallback.[5]
This provides useful separation between the application and the underlying model(s).
But building the reference environment reinforced an important lesson: Model governance is not the same thing as agent governance.
A governed model connection does not answer:
Who can invoke a particular tool?
Which information can that tool retrieve?
Can the capability send data to an external destination?
Does the user need to approve the action?
Can one integration be independently disabled?
What information reaches operational telemetry?
Those controls exist around the model.
That is why enterprise AI architecture increasingly needs to treat the model as one component of a larger system rather than as the system itself.
Observability Without Creating Another Data Leak
Agentic systems need observability.
Operators need enough information to diagnose failures, investigate abnormal behaviour, troubleshoot integrations, and determine whether systems are operating as intended.
Workers provides logging and observability capabilities for application events, errors, requests, and runtime behaviour.[6] AI Gateway can similarly collect model-level information, including requests and responses depending on how logging is configured.[5]
That last point matters.
AI telemetry can itself become a security and privacy concern. Prompts may contain sensitive information. Tool responses may contain proprietary information. Authentication material can accidentally enter application context.
Logging entire transactions indiscriminately can create a secondary dataset containing precisely the information an organization was attempting to protect.
The KrisperTech reference architecture therefore applies data minimization to telemetry as well. Operational logging is intended to describe system behaviour without recreating the contents of user interactions inside the logging system.
The principle is straightforward: Log enough to investigate the system without rebuilding the sensitive system inside the logs.
As AI applications become connected to more organizational information, that distinction becomes increasingly important.
The Reusable Pattern
When the implementation-specific details are removed, the resulting security architecture is surprisingly familiar.
An authenticated identity enters a controlled application.
The application exposes only defined capabilities.
Meaningful trust transitions require authorization.
Internal services communicate through explicit boundaries.
External connections are visible.
Information retrieval is constrained.
Activity is observable.
None of these concepts is unique to artificial intelligence. What is changing is the entity consuming them.
Increasingly, that entity is an AI agent capable of reasoning about what action should happen next. Traditional security disciplines such as identity, least privilege, segmentation, authorization, data classification, monitoring, change control, and incident response therefore need to extend into agentic workflows.
From Zero Trust to Agent Trust
Zero Trust challenges the assumption that being inside a trusted network should confer broad access. NIST describes the model as removing implicit trust based on network location or asset ownership and requiring explicit authentication and authorization around protected resources.[7]
Agentic AI requires a similar shift.
An agent should not automatically be trusted because the organization deployed it.
A tool should not automatically be trusted because it is internal.
An action should not automatically be permitted because the user is authenticated.
And information should not automatically become available because the model might find it useful.
Instead, trust can be evaluated across several relationships: User → Agent → Capability → Data
and, where necessary:
Agent → Model
Capability → External Service
Each transition can represent a separate policy decision.
This is why agent authorization may increasingly become an extension of identity architecture rather than simply an application-development concern.
What This Architecture Does Not Claim
This environment is an evaluation deployment, not a universal production blueprint.
It is intentionally designed not to process confidential or customer-proprietary information.
It also does not demonstrate every control that a production agentic AI environment may require, including fine-grained authorization boundaries around MCP-connected tools or end-to-end, identity-driven observability across users, agents, and sub-agents.
A production system handling sensitive organizational data could require considerably stronger controls around data classification, identity-aware authorization at individual sources, retention, auditing, revocation, secrets management, regulatory requirements, model-risk management, incident response, and isolation.
The point of the reference architecture is not that its controls solve every AI-security problem.
The point is that the trust boundaries are made explicit enough that additional controls have somewhere meaningful to attach.
The Larger Challenge
The easiest part of modern AI adoption may increasingly be connecting an application (or harness) to capable model(s).
The harder questions are what happens around that model.
What can the AI see?
What can it invoke?
What can it change?
Where can it send information?
Who approved the action?
And what evidence remains afterward?
As agents become more capable, they increasingly resemble a new class of privileged digital actor.
Organizations therefore need to move beyond policies that simply state which AI applications employees may use.
Some AI governance will need to become enforceable architecture. The objective should not be to eliminate the capabilities that make AI useful. It should be to place defensible boundaries around those capabilities.
That brings the discussion back to the question that motivated this reference implementation: How do we give an AI agent enough authority to create meaningful value without giving it more trust than the task requires?
Answering that question may become one of the defining cybersecurity architecture challenges of the agentic AI era.
References
[1] Jones, P. and Carter, D. Cloudflare OS: an open platform for agents, apps, and work. Cloudflare Blog, August 2026. Cloudflare Blog Cloudflare OS article
[2] Cloudflare. Cloudflare OS: An AI productivity environment. Open-source project documentation. The project describes Gatekeepers as a capability-based security layer for mediating agent and application access to external resources. GitHub Cloudflare OS GitHub repository
[3] Cloudflare. Publish a self-hosted application to the Internet — Cloudflare Access. Cloudflare Developer Documentation. Cloudflare Docs Cloudflare Access documentation
[4] Cloudflare. Service bindings — Cloudflare Workers. Cloudflare Developer Documentation. Cloudflare Docs Workers service bindings documentation
[5] Cloudflare. Cloudflare AI Gateway and AI Gateway Observability. Cloudflare Developer Documentation. Cloudflare Docs AI Gateway documentation
[6] Cloudflare. Workers Logs. Cloudflare Developer Documentation. Cloudflare Docs Workers Logs documentation
[7] Rose, S., Borchert, O., Mitchell, S., and Connelly, S. NIST Special Publication 800-207: Zero Trust Architecture. National Institute of Standards and Technology, 2020. NIST Computer Security Resource Center NIST SP 800-207
[8] OWASP GenAI Security Project. LLM06:2025 Excessive Agency. OWASP Top 10 for Large Language Model Applications. OWASP Gen AI Security Project OWASP Excessive Agency guidance
[9] Cloudflare. Certificate Transparency Monitoring. Cloudflare SSL/TLS Documentation. Cloudflare Docs Certificate Transparency Monitoring documentation
Comments