KitForge: Design AI Agents With Enforced Guardrails, Then Validate Them

Most tools that help you build AI agents stop at the prompt. You describe what you want, you get a system prompt or a chain of calls, and the question of whether that agent is safe to deploy is left as an exercise for the reader. KitForge was built for the opposite premise: that the governable structure of an agent — its worst-case action, its tool boundary, the steps that must stop for a human — is the part worth designing first, and the part worth validating before anything ships. This article walks through how to use KitForge to design an agent blueprint with guardrails that actually enforce, and then how to run that same design through the Compliance Scanner to get a governance score and a concrete fix-list. The two together form a design-to-validation loop that, as far as we know, does not exist anywhere else.

If you have never thought about agents in terms of authority rather than capability, read how to design safe AI agents first — it explains the worst-case-action mindset this workflow assumes. Everything below builds on it.

What KitForge is, and what makes it different

KitForge is a browser-based composer for designing AI agent blueprints under a governance schema. You name the agent, describe its job, list the tools it needs, and mark which of those tools take irreversible action. From that, KitForge generates two things: a machine-readable agentaz.json manifest that classifies the agent by its worst-case action, and a runnable scaffold whose safety layer enforces the approval gates rather than merely documenting them. That word — enforces — is the whole point. In most agent code, "human-in-the-loop" is a sentence in a system prompt, which a model is free to ignore under the right pressure. In a KitForge scaffold, a gated tool call is blocked at the runtime boundary. A missing or unapproved capability is a wall, not a request.

The governance schema underneath is AgentAz, an open specification that describes an agent's Trust Level (A1 read-only through A5 full autonomy), its authority boundary, its tool and output boundaries, and the loop and cost limits that keep it bounded. AgentAz is design-time: it specifies, your runtime enforces. KitForge is what makes that specification quick to produce and hard to get wrong.

How to use KitForge, step by step

1. Start from the worst-case action, not the feature. Before you list a single tool, write one sentence: what is the most damaging thing this agent could do if every check failed? For a refund agent, it is "issue a refund to the wrong account." For a support agent, it is "send a customer a commitment we can't honor." That sentence sets the Trust Level and decides which tools must be gated. KitForge asks for it first on purpose.

2. List the tools — and split read from write. Give the agent broad read access (the safe, high-volume enrichment work) and narrow, gated write access (the few actions it could regret). In the composer, each tool is a row with a name, a description, and an approval flag:

// A KitForge tool row
{ name: "lookup_order",   description: "Read order + payment status", approval: false }
{ name: "check_policy",   description: "Read refund policy for the SKU",  approval: false }
{ name: "issue_refund",   description: "Move money back to the customer", approval: true  }

The two reads run freely; issue_refund is marked approval: true, which is the single most consequential decision in the whole design. Everything downstream flows from it.

3. Let KitForge generate the manifest. From those inputs, KitForge produces the agentaz.json manifest — the audit-ready artifact a security or compliance team can actually read. It looks like this:

{
  "name": "Refund Resolution Agent",
  "purpose": "Resolve refund requests within policy, escalate the rest",
  "version": "1.0.0",
  "trust_level": "A3",
  "dna_pattern": "retrieve - reason - propose - gate - act",
  "worst_case_action": "Issue a refund to the wrong account",
  "authority_boundary": {
    "can_modify_records": true,
    "can_delete_records": false,
    "can_send_messages": true,
    "can_spend_money": true,
    "can_access_customer_data": true,
    "can_access_financial_data": true
  },
  "tool_boundary": ["lookup_order", "check_policy", "issue_refund"],
  "output_boundary": ["refund_decision", "escalation_ticket"],
  "cost_boundary": { "max_spend_per_action": 200, "requires_human_approval": true },
  "loop_boundary": { "max_iterations": 6, "has_escape_hatch": true }
}

This manifest is the thing that makes an agent governable. It is not a description of how the model thinks; it is a declaration of what the agent is allowed to do, framed by its worst case. A reviewer who has never seen your code can read it in thirty seconds and tell you whether the boundary is right.

4. Generate the scaffold with enforced gates. Alongside the manifest, KitForge generates a runnable scaffold. The generated blueprint expresses each tool as a node, and the governance block names exactly which nodes require human approval and how long an approval may wait:

"governance": {
  "require_human_approval_for": ["call_issue_refund"],
  "approval_timeout_seconds": 3600
},
"safety": {
  "max_iterations": 6,
  "escape_hatch": true
}

The enforcement is not advisory. In the scaffold's safety layer, a call to a gated node is intercepted before execution. If approval has not been granted, the call does not run — the agent escalates instead:

# Enforced at the runtime boundary, not in the prompt
def call_tool(node, args, approvals):
    if node.requires_approval and node.id not in approvals:
        raise ApprovalRequired(node.id)   # blocked, then escalated
    return TOOLS[node.id](**args)

This is the difference between an agent that says it will ask before refunding and one that cannot refund without an approval token. The model can be jailbroken, confused, or wrong; the boundary holds regardless, because it lives outside the model. For the deeper rationale on why authority limits beat model intelligence, see the agent engineering stack.

A note on what "enforces" means here. Enforcement is a property of the scaffold KitForge generates and the runtime you wire it into — not a blanket guarantee about every blueprint in the registry. How much of an agent's safety is enforced in code versus expressed at the prompt layer varies by kit, by its tier (Basic, Advanced, or Enterprise), and by which tools it gates. A read-only A1 research kit has almost nothing to enforce; a money-moving A3 kit should enforce its gate in code, and its Enterprise tier will go further than its Basic one. The honest way to know where any given agent sits is to scan it: the Compliance Scanner reports which controls are actually enforced and which are only described, so you are never guessing.

The Compliance Scanner: what it checks

Designing a governable agent is half the job. The other half is proving it. The Compliance Scanner takes an agent's system prompt or its agentaz.json and scores it against the design-layer controls in Microsoft's published agent-governance guidance, with AgentAz as the companion mapping that shows how each control is met at the prompt and specification layer. It returns four things: a set of pass/fail governance gates, the specific failure scenarios the agent is exposed to, a risk radar, and a copy-paste fix block you can paste straight back into your design.

Two properties matter for trust. First, the scan runs deterministically on the edge — the curated rule set lives server-side, so the same input always yields the same result and the rules are never shipped to the browser to be gamed. Second, the submitted prompt is never stored and never sent to a model. The scanner is a static analyzer for agent governance, not an LLM grading another LLM. That makes it safe to run on prompts you would never paste into a chat window.

Using KitForge and the Scanner together: the design-to-validation loop

Here is where the two tools stop being separate features and become a workflow. KitForge has a "Scan this design" action that takes the blueprint you just composed and opens it directly in the Compliance Scanner. You design the boundary, then immediately validate it — without leaving the tool, without hand-copying anything, without waiting for a review cycle. The loop is:

Design - generate - scan - fix - re-scan - ship. You compose the agent in KitForge, generate the manifest and scaffold, scan the design, read the failing gates, fix them in the composer, and scan again until the gates pass. Only then do you ship. This is continuous governance applied to agent design the way continuous integration is applied to code — and it is the part of this workflow that genuinely does not exist in other tooling. Prompt marketplaces sell you the prompt. Agent frameworks give you the loop. Neither tells you, before deployment, whether the agent you just built would survive a governance review.

A worked example, end to end

Take the refund agent above. You compose it in KitForge with issue_refund gated, generate the manifest, and hit "Scan this design." Suppose the scan comes back with one failing gate: cost ceiling not enforced. The agent can issue refunds up to any amount because, while you set max_spend_per_action in the manifest, the scaffold's gate triggers only on the action, not on the amount. The fix block tells you exactly what to add — a cost check that escalates any refund above the ceiling even when an approval token is present:

def guard_refund(amount, approvals, node):
    if amount > MANIFEST["cost_boundary"]["max_spend_per_action"]:
        raise EscalateForReview("over_ceiling", amount)   # always human
    if node.requires_approval and node.id not in approvals:
        raise ApprovalRequired(node.id)
    return True

You add the cost guard in your scaffold, re-scan, and the gate passes. The whole cycle took minutes, and the artifact you walk into a deployment review with is no longer "trust me, it asks first" — it is a manifest with a green governance scan attached. That is a categorically stronger position than a hand-written agent with a paragraph of good intentions in its prompt.

When this workflow is worth it

Not every agent needs it. A read-only research assistant at Trust Level A1 has no irreversible action to gate, and the scan will tell you so in one pass. The workflow earns its keep the moment an agent can do something it cannot undo — move money, grant access, delete records, send commitments. Those are exactly the agents that fail in production, and exactly the ones a security team will block without a reviewable boundary. KitForge makes the boundary fast to design; the Compliance Scanner makes it fast to prove. Use them together for any agent above A2, and use the scan alone whenever you want to grade an agent you built elsewhere — the scanner does not care whether KitForge produced the input.

If you want a ready-made example to study instead of starting from scratch, browse the blueprint registry: every kit ships with an AgentAz manifest and a runnable starter, so you can scan an existing design, see what a passing governance profile looks like, and adapt it. The fastest way to learn the loop is to scan a kit you trust, then scan one of your own and compare the gates.

What the scan actually checks

It helps to know what a governance scan looks for, because the gates map directly to the fields KitForge asks you to fill in. A compliance scan of an agent design typically evaluates whether: the agent declares a worst-case action and a Trust Level at all; irreversible tools sit behind a human approval gate; the tool boundary is least-privilege rather than open-ended; there is a cost ceiling on any action that spends money; the loop has a maximum-iteration cap and an escape hatch so the agent cannot spin forever; outputs are constrained to a declared set rather than free-form; and the agent has an explicit escalation path for low-confidence or out-of-policy cases. Each of these is a gate that passes or fails, and each maps to a recognized design-layer control.

The reason designing in KitForge first makes the scan easy is that the composer already collects every one of these inputs — the worst-case sentence, the per-tool approval flags, the cost and loop boundaries, the output boundary. A blueprint assembled in KitForge arrives at the scanner with most gates pre-satisfied, so the scan becomes a confirmation step rather than a list of surprises. When you scan an agent built elsewhere — a raw system prompt with no manifest — the same gates tend to come back red, not because the agent is bad, but because the governance was never made explicit. The scan's value is forcing that structure into the open, where a reviewer can see it. For a fuller treatment of the underlying controls, see how to design safe AI agents and the AgentAz specification itself.

The short version

KitForge is for designing AI agents whose guardrails enforce, not merely advise. The Compliance Scanner is for proving those guardrails hold before you deploy. Used together — design in KitForge, validate with the Scanner, fix, re-scan, ship — they turn agent governance from a document you write after the fact into a check you pass before launch. Start a design in KitForge, and when you have a boundary you believe in, scan it.