Part 3: Runtime Governance for KrisperBot: Agent Identity, MCP Access, and Tool Scope on Cloudflare

Kristopher Persad
Jun 28
17 min read

Publication Scope and IP Boundary: This reference architecture is a personal KrisperTech publication based on public Cloudflare services, publicly available documentation, and a personal demo implementation. It is not an official Cloudflare product document. It does not disclose Cloudflare internal material, customer architecture, roadmap information, proprietary field assets, internal enablement content, source code, private configuration, secrets, or customer-specific implementation patterns. The purpose of this article is to explain a reusable architecture pattern for deploying a secure AI assistant using publicly available Cloudflare developer and security services.

The purpose of this article is to explain a reusable architecture pattern for governing an AI agent runtime using Cloudflare developer and security services.

The first phase of the KrisperTech AI assistant reference architecture proved that a full-stack AI agent could be built on Cloudflare. The second phase hardened the implementation.

The assistant moved to a model better suited for structured tool use. The inference path was aligned with AI Gateway so logging, visibility, and policy controls applied to the actual request flow. The retrieval pattern was changed from general link crawling to deterministic sitemap-based article discovery.

Those changes made KrisperBot more reliable.

This third phase focuses on a different question: Once an AI agent can use tools, how do we make sure those tools are scoped, authenticated, observable, and revocable?

That question matters because an AI agent is not only a model responding to prompts.

A model generates output.

An agent operates inside a runtime.

That runtime may maintain session state, decide whether tools are needed, invoke external capabilities, retrieve content, and return grounded answers to the user. Once tools are introduced, the security model has to account for more than model behaviour. It has to account for what the agent is allowed to do.

For KrisperBot, this does not mean broad enterprise automation.

KrisperBot is intentionally read-only. It helps users find and understand public KrisperTech content. It does not send emails, create tickets, update SaaS platforms, modify backend systems, perform financial actions, or write to enterprise applications.

That limited scope is deliberate.

But even a read-only agent still needs runtime governance. It accepts user prompts, reasons over intent, invokes tools, authenticates to an MCP server, retrieves website content, and returns generated answers. Each of those steps creates a boundary that should be designed, constrained, and observed.

The goal of this phase was not to make KrisperBot more autonomous.

The goal was to keep the agent useful while ensuring that its authority remains narrow, visible, and controlled.

From Production Hardening to Runtime Governance

The Phase 2 hardening work focused on whether the architecture behaved correctly under realistic testing.

Three areas were adjusted:

The model needed to reliably support structured tool use.
The inference path needed to support the intended AI Gateway governance controls.
The retrieval layer needed deterministic article discovery instead of general link crawling.

That work was important because agentic systems are chains of components. The model has to produce the right type of output. The runtime has to interpret it. The tool layer has to be protected. The retrieval layer has to return the right content. The control plane has to see the requests it is expected to govern.

Phase 3 builds on that foundation.

The focus is no longer only whether KrisperBot can call tools reliably. The focus is whether tool use is bounded by identity, access control, runtime instructions, retrieval scope, telemetry, and revocation paths.

In other words: Can the agent use tools?

Became: Which tools can the agent use, through which identity, against which data source, under which observable control path?

That is the runtime governance problem.

Why a Read-Only Agent Still Needs Runtime Controls

It is tempting to think that a read-only agent is low risk by default.

That is only partly true.

Read-only scope reduces the blast radius because the agent cannot directly modify systems. However, it does not eliminate the need for governance. A public-facing AI assistant can still be abused, misdirected, overused, prompted to invent content, or pushed into retrieval behaviour that was never intended.

For KrisperBot, the intended behaviour is narrow:

Answer general cybersecurity questions when appropriate.
Use tools when live KrisperTech article content is needed.
Query the KrisperTech article index.
Fetch exact KrisperTech article content when the user asks for a specific article or topic.
Avoid arbitrary website browsing.
Avoid constructing, guessing, shortening, or modifying article URLs.
Stay grounded when using KrisperTech content.

That behaviour has to be designed into the runtime. It cannot be left to the model alone.

The important distinction is this: The model can decide that a tool might be useful.

The architecture decides which tools exist, who can reach them, what they can retrieve, how often they should be used, and where activity is logged.

That is the difference between an AI assistant with tools and a governed AI agent runtime.

Governance Decision 1: Give the Agent a Dedicated Machine Identity

The first runtime governance decision was to avoid treating MCP access as an anonymous backend call.

KrisperBot accesses the MCP tool layer using a dedicated Cloudflare Access service token. This gives the agent a machine-to-machine identity path instead of relying on open reachability, shared user context, or an unprotected endpoint.

That matters because MCP is the tool boundary.

The public user interacts with the chat interface. The chat interface reaches the agent runtime. The agent runtime is the component that can reach the MCP server. The MCP server is not intended to be generally reachable by arbitrary clients.

This creates a cleaner separation:

The user can ask questions.
The agent can reason over the question.
The agent can authenticate to the MCP server.
The MCP server can expose only the approved tools.

Cloudflare Access service tokens are designed for automated workflows where no human user is present. Cloudflare’s documentation also notes that service token names help identify related events in logs and that deleting a service token revokes access for services that rely on it. [1]

That is important for AI agents because they behave more like non-human identities than traditional user sessions.

A production agent should have a distinct access path. Operators should be able to identify it in logs, rotate its credentials, remove its access, and understand which systems depend on it.

For KrisperBot, the agent identity is intentionally narrow. It exists to let the assistant reach the protected MCP layer. It does not provide broad administrative access, general SaaS access, or write authority.

That is the right model for this use case.

Governance Decision 2: Keep MCP Behind an Access Boundary

The second runtime governance decision was to keep the MCP server protected.

MCP is useful because it gives AI applications a structured way to connect to external tools, context, and data sources. The MCP specification describes the protocol as a way for LLM applications to integrate with external data sources and tools. [2]

That capability is powerful.

It also creates a security boundary.

Once an agent can use MCP tools, the tool layer should not be treated as a casual internal helper. It becomes the place where the agent reaches beyond pure text generation and interacts with external capabilities.

For KrisperBot, the MCP server is protected by Cloudflare Access. The agent authenticates using its service token before it can interact with the MCP endpoint. Cloudflare also documents MCP server portal patterns where Access and service tokens can be used to secure MCP server access. [3]

The architectural point is simple: The MCP server is not exposed as an unauthenticated public tool endpoint.

That matters because the MCP layer is where tool capabilities are made available to the agent. Even when those tools are read-only, the tool server should still sit behind an intentional access boundary.

For KrisperBot, Access controls which machine identity can reach the MCP server.

The MCP implementation then controls what that authenticated agent can actually do.

Those are separate but complementary controls.

Access answers: Is this agent allowed to reach the MCP server?

The MCP tool design answers: Once authenticated, what can the agent query or retrieve?

In this implementation, the answer is intentionally narrow: KrisperBot can query KrisperTech article information and retrieve matching KrisperTech article content. It cannot use the MCP server to browse arbitrary websites or perform unrelated actions.

Governance Decision 3: Bind Only the Approved Tools Into the Agent Runtime

The third governance decision was to control the tool surface that the model sees.

KrisperBot does not receive open-ended browsing capability. It receives a bounded MCP tool set through the agent runtime.

That distinction matters.

An AI agent should not be handed every capability simply because the underlying platform can expose it. Tools are operational authority. Even read-only tools should be scoped to the purpose of the agent.

For KrisperBot, the available tool behaviour is intentionally limited:

One tool can return the available KrisperTech article list, including exact URLs and article metadata.
Another tool can fetch the full content of a specific KrisperTech article using an exact URL.

That is the approved tool surface.

The assistant’s behaviour instructions reinforce this design. The agent is instructed to use the article index when asked about available articles, covered topics, or recent posts. It is instructed to use the page retrieval tool only with exact URLs returned from the article index. It is also instructed that KrisperTech article URLs must start with the expected KrisperTech post path and that URLs should not be constructed, guessed, shortened, or modified.

That is important because URL handling is part of the trust model.

If an agent can invent URLs, modify URLs, or retrieve arbitrary destinations, then retrieval scope becomes ambiguous. For KrisperBot, retrieval is designed to stay inside the KrisperTech content boundary.

The model may decide a tool is useful.

But the runtime only provides the approved MCP tools.

The tool instructions define when those tools should be used.

The MCP implementation limits what those tools can retrieve.

That layered approach is stronger than relying on the model to behave correctly on its own.

Governance Decision 4: Bound the Tool Loop

The fourth governance decision was to limit the agent’s tool-use loop.

Agentic systems can behave differently from simple request-response chatbots because they may reason, call a tool, inspect the result, continue reasoning, call another tool, and repeat that cycle.

That loop is useful.

It is also something that needs boundaries.

For KrisperBot, the runtime includes a maximum step count for the model/tool interaction. That means the assistant has a bounded number of reasoning and tool-use steps within a response cycle.

This is not the same as a full enterprise policy engine.

It is a practical runtime constraint.

It helps reduce the chance that a malformed prompt, confusing retrieval result, or unexpected tool response causes the agent to continue looping longer than intended. It also supports cost and reliability control because every extra reasoning step can create additional inference and tool activity.

This is one of the lessons from production agent design:

Budgets matter.

A public assistant should not have unlimited inference, unlimited retrieval, or unlimited tool-calling behaviour. Even when the tools are read-only, the runtime should define how far the agent can go.

For KrisperBot, the relevant boundaries include:

A narrow tool set.
A defined article retrieval scope.
A maximum tool/reasoning step count.
AI Gateway visibility and usage controls.
Cloudflare Access enforcement for MCP access.
Worker-level logs for runtime serviceability.

Together, those controls help keep the agent useful without making its behaviour open-ended.

Governance Decision 5: Keep Retrieval Scoped to KrisperTech Content

The fifth governance decision was to preserve the deterministic retrieval model from Phase 2.

KrisperBot is designed to answer questions about KrisperTech content. The hardened retrieval path uses article discovery and exact article retrieval rather than arbitrary web browsing.

This matters because retrieval is not just a performance feature. It is part of the security model.

If an assistant can retrieve from anywhere, users may push it toward sources the operator did not intend to trust. That can create prompt injection risk, weak grounding, irrelevant results, or unexpected data handling concerns.

For this implementation, KrisperBot is clear about its retrieval boundary.

If a user asks it to fetch or browse other websites, the agent should not attempt to do that. The expected response is that it can only access KrisperTech.com directly and does not have tools to browse or fetch live content from other websites.

That is an important governance behaviour.

The agent is not pretending to be a general-purpose browser.

It is a KrisperTech content assistant.

That scope makes the architecture easier to reason about. It also makes observability more meaningful because tool calls should align with a narrow set of expected actions.

For enterprise adaptations, the same pattern can apply to internal sources:

A policy library.
A knowledge base.
A support portal.
A product documentation site.
A ticket metadata API.
A controlled document index.
A vector search layer.

The point is not that every agent should read from a blog.

The point is that every agent should have a defined retrieval boundary.

Governance Decision 6: Put Inference Through AI Gateway

The sixth governance decision was to keep the model path observable.

In this architecture, inference traffic passes through Cloudflare AI Gateway. AI Gateway provides visibility and control for AI applications, including analytics, logging, caching, rate limiting, retries, model fallback, and related controls depending on configuration and request path. [4]

That control plane matters because agent behaviour is not visible enough if operators only see frontend requests.

A user prompt may lead to:

An inference call.
A tool decision.
A retrieval request.
Another inference step.
A streamed response.

Without visibility into the AI request path, it becomes difficult to understand how the assistant is being used, whether costs are abnormal, whether prompts are triggering unexpected behaviour, or whether latency is increasing.

AI Gateway also supports rate limiting and spend limits. Cloudflare documents spend limits as a way to set cost-based budgets on an AI Gateway, where requests can be blocked with a 429 response once the configured limit is reached within a time window. [5]

For a public-facing assistant, that matters.

AI systems can be abused economically even when they do not expose sensitive data. A public chatbot connected to inference and retrieval can be targeted for cost generation, automation, scraping-like behaviour, or repeated prompt abuse.

AI Gateway does not replace application security.

But it gives the inference path a control point.

For KrisperBot, that is one part of the runtime governance model.

Governance Decision 7: Be Honest About Streaming Trade-offs

KrisperBot uses streaming because user experience matters.

When an assistant needs to reason, retrieve content, and generate an answer, a blank screen creates uncertainty. Streaming makes the system feel responsive and helps the user understand that work is happening.

But streaming has trade-offs.

Not every AI control behaves the same way with streamed responses as it does with non-streamed responses. Cloudflare’s AI Gateway Guardrails documentation notes that Guardrails do not yet support streaming responses. [6] Cloudflare’s DLP documentation also explains that response-side scanning for streamed Server-Sent Events may require buffering before delivery, which changes the normal streaming experience. [7]

That means the architecture has to be honest about the chosen path.

For KrisperBot, streaming was retained because the agent is read-only, scoped to KrisperTech content, and constrained through the MCP and retrieval design. That makes the trade-off acceptable for this implementation.

For a different agent, the answer might change.

If an agent can send emails, create tickets, update records, trigger workflows, or perform privileged actions, then the response path, approval model, and policy enforcement requirements become more demanding. In that scenario, non-streamed enforcement paths, request-only controls, stronger approval gates, or additional runtime inspection may be appropriate.

The lesson is not that streaming is bad.

The lesson is that user experience choices are also security architecture choices.

Governance Decision 8: Observe the Runtime Across Multiple Layers

The eighth governance decision was to make sure the architecture leaves evidence.

For KrisperBot, observability exists across several layers:

AI Gateway provides visibility into the inference path.

Cloudflare Access provides visibility into MCP authentication events.

Workers logs provide serviceability data for the agent runtime and MCP components.

Cloudflare application services provide web request telemetry at the edge.

That layered visibility matters because agent behaviour crosses layers.

A traditional web application request may be relatively direct: user request, application logic, response.

An AI agent flow can be more complex:

User prompt.
Session state.
Model reasoning.
Tool selection.
MCP access.
Content retrieval.
Tool result.
Additional reasoning.
Final response.

If operators only observe one layer, they may miss important behaviour in another.

For example, AI Gateway can show inference activity, but it does not replace MCP access logs. Access can show that the service token reached the MCP endpoint, but it does not replace tool-level behaviour and Worker runtime logs. Worker logs can support debugging, but they do not replace AI usage analytics or edge traffic visibility.

The value comes from the combination.

That is especially important for incident response. If the assistant behaves unexpectedly, the operator should be able to investigate the inference path, MCP access path, runtime logs, and edge request path together.

This is where AI governance becomes operational.

Governance is not only a policy statement.

It is the ability to answer what happened, which identity was involved, which tool was used, what system was reached, and how the architecture enforced its boundaries.

Governance Decision 9: Design for Revocation

The ninth governance decision was to preserve revocation paths.

Every production agent should have a way to stop or limit its authority.

For KrisperBot, revocation exists at multiple layers.

The service token can be deleted or rotated.

The Cloudflare Access policy can be changed.

The MCP server can be disabled or modified.

The Worker route can be changed or disabled.

AI Gateway controls can limit or block inference usage depending on configuration.

Those are practical control paths.

This implementation does not currently depend on a separate application-level toggle that disables MCP tools before they are passed into the model runtime. That would be a useful additional control in future versions, but it is not required for the current read-only design.

The key point is that tool availability is governed through the MCP boundary, Cloudflare Access, service-token authentication, the narrow design of the exposed tools, and the deployment configuration of the Worker and MCP server.

That is the right level of control for this agent’s current purpose.

For agents with write access, stronger revocation patterns would be required. Those could include workflow-level pause controls, queue draining, tool-specific disablement, approval revocation, credential scoping by action type, and rollback procedures for completed actions.

KrisperBot does not need that level of complexity because KrisperBot does not perform write actions.

That is an intentional design decision.

What This Agent Deliberately Does Not Do

Part of governance is being clear about what is out of scope.

KrisperBot does not act as a general-purpose autonomous enterprise agent.

It does not have access to internal systems.

It does not authenticate as a user into SaaS applications.

It does not send messages.

It does not create tickets.

It does not update records.

It does not initiate payments.

It does not execute administrative workflows.

It does not perform destructive actions.

It does not require human approval gates today because it does not expose write capabilities.

That last point is important.

Human approval gates are valuable when an agent can take sensitive, irreversible, externally visible, privileged, or financially material actions. For KrisperBot, the better design choice is not to add approval gates artificially. The better design choice is to keep the agent read-only and tightly scoped.

If future versions add write actions, then the architecture should change.

At that point, each write-capable tool should have its own policy, authorization scope, approval requirement, logging requirement, and revocation path.

That is not the current design.

The current design is a governed read-only public content assistant.

Before and After

The Phase 3 runtime governance work did not rebuild the assistant.

It clarified and strengthened how authority is assigned, constrained, observed, and revoked.

Area	Earlier Pattern	Runtime Governance Pattern	Reason
Agent identity	Agent could call protected tooling	Agent uses a dedicated service-token identity for MCP access	Machine access should be attributable and revocable
MCP access	MCP server protected by Access	MCP remains behind Access and is intended to be reached only by the agent identity	Tool servers should not be open public endpoints
Tool surface	MCP tools available to the agent	Only scoped KrisperTech article discovery and article retrieval tools are exposed	Tool access should match the agent’s purpose
Retrieval	Sitemap-based discovery and article extraction	Retrieval remains constrained to KrisperTech article content	Grounding should stay inside the trusted content boundary
Tool behaviour	Agent can use tools when needed	Runtime instructions define when tools are used, how URLs are handled, and how often discovery should occur	The model should not invent retrieval paths
Tool loop	Agent can perform multi-step reasoning	Runtime step count bounds the reasoning and tool-use loop	Agent behaviour should not be unlimited
Inference path	AI Gateway in the request path	AI Gateway remains the inference control plane	Inference needs visibility, limits, and policy controls
Observability	AI Gateway and Access visibility	AI Gateway, Access, Workers logs, and edge telemetry provide layered evidence	Inference needs visibility, limits, and policy controls
Revocation	Protected components could be changed	Service tokens, Access policy, MCP deployment, Worker routes, and AI Gateway controls provide revocation options	Agent authority should be removable
Approval	Not implemented	Not required for current read-only scope	Approval gates matter when agents can perform sensitive actions

The important point is not that every possible control has been added.

The important point is that the controls match the risk of the agent.

KrisperBot is read-only, public-content scoped, and intentionally narrow. Its governance model reflects that.

Practical Lessons for AI Agent Architecture

Phase 3 produced several lessons that apply beyond this specific implementation.

1. Treat agent access as non-human identity access

An AI agent should not casually inherit broad user access, shared backend credentials, or anonymous reachability.

If the agent needs to reach tools, it should have an identifiable access path that can be logged, rotated, and revoked.

For KrisperBot, that access path is a dedicated Cloudflare Access service token used for MCP access.

2. Do not expose tools just because the model can use them

Tools are capabilities.

A tool may only read content today, but in other architectures a tool may write data, trigger a workflow, query sensitive records, or call another system.

The agent should receive only the tools it needs for its purpose.

For KrisperBot, that means article discovery and article retrieval.

3. Keep the tool server behind an access boundary

MCP is a useful pattern because it separates the agent from its tools.

That separation becomes more valuable when the MCP server is protected, logged, and governed.

A separate tool layer gives the architecture a cleaner place to apply authentication, authorization, monitoring, and future policy controls.

4. Treat retrieval scope as part of security

Retrieval determines what content the model uses to answer.

If retrieval is open-ended, the trust model becomes open-ended.

For KrisperBot, retrieval is scoped to KrisperTech content. That makes the assistant more predictable and easier to govern.

5. Bound the agent loop

Agentic behaviour should not be unlimited.

Step limits, tool budgets, rate limits, spend limits, and retrieval constraints all help prevent runaway behaviour.

Even when the agent is read-only, resource usage and operational reliability still matter.

6. Validate the real control path

It is not enough to configure a control somewhere in the platform.

The application’s real traffic path has to pass through it.

That lesson carried forward from Phase 2. In Phase 3, the same principle applies to MCP access, tool exposure, inference, telemetry, and revocation.

7. Do not add fake approval gates

Security controls should match the system.

KrisperBot does not need human approval gates because it does not perform write actions. Adding approval prompts to a read-only article assistant would create complexity without meaningful risk reduction.

The better control is to keep the agent read-only.

Security Takeaways

AI security is not only about prompt injection.

It is about what the agent can do after the prompt.

For KrisperBot, the runtime governance model includes:

A dedicated machine identity for MCP access.

Cloudflare Access protecting the MCP tool server.

A bounded MCP tool set.

KrisperTech-only article retrieval.

Instructions that prevent URL guessing or arbitrary retrieval.

A maximum reasoning and tool-use step count.

AI Gateway in the inference path.

Layered telemetry across inference, access, runtime, and edge services.

Revocation paths through service token deletion or rotation, Access policy changes, MCP changes, Worker route changes, and AI Gateway controls.

No single control makes the agent safe.

The value comes from the combination of controls and from keeping the agent’s authority aligned to its purpose.

KrisperBot is not a general-purpose autonomous operator.

It is a governed, read-only assistant for KrisperTech content.

That is the right scope for this implementation.

Conclusion

The first version of KrisperBot proved that a full-stack AI agent could be built on Cloudflare.

The second phase hardened the architecture so the model, inference path, and retrieval strategy behaved more predictably.

This third phase focused on runtime governance.

Once an agent can use tools, the security question changes.

It is no longer only: Can the model answer?

It becomes: What is the agent allowed to do?

For KrisperBot, the answer is intentionally narrow.

The agent can use a dedicated machine identity to reach a protected MCP server. It can query the KrisperTech article index. It can retrieve exact KrisperTech article content. It can answer users based on that scoped public content. It cannot browse arbitrary websites, perform write actions, or operate outside its purpose.

That is the core lesson.

A chatbot responds.

An agent acts.

A governed agent acts within boundaries.

As enterprises adopt AI agents, the most important security work will not be limited to safer prompts or better model selection. Those matter, but they are only part of the system.

The larger challenge is runtime governance: identity, access, tool scope, retrieval boundaries, observability, and revocation.

That is how agentic AI moves from a working demo to a governable architecture.

References

[1] Cloudflare One documentation: Service tokens

https://developers.cloudflare.com/cloudflare-one/access-controls/service-credentials/service-tokens/

[2] Model Context Protocol specification, 2025-06-18

https://modelcontextprotocol.io/specification/2025-06-18

[3] Cloudflare One documentation: MCP server portals

https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/

[4] Cloudflare AI Gateway documentation

https://developers.cloudflare.com/ai-gateway/

[5] Cloudflare AI Gateway documentation: Spend limits