How to Add Governance to Custom AI Agents
Built your own agent framework? Cordum governs it. CAP v2 gives any agent policy checks, approvals, and audit trails.
The problem with ungoverned Custom Agents agents
- When you build your own agent framework, governance is something you have to build too, or do without. Off-the-shelf safety tooling assumes a framework you are not using.
- Hand-rolled policy ends up as if-statements scattered through the code path. Changing a rule means a code change, a review, and a deploy cycle, so policy can never move faster than your release train.
- Audit trails tend to be an afterthought bolted on late. Logs are unstructured, inconsistent between agents, and rarely link a decision back to the rule that produced it.
- As the fleet grows, every agent governs itself slightly differently. That divergence is exactly what makes a custom-agent estate hard to reason about and harder to prove compliant.
How Cordum governs Custom Agents
Integrate via the CAP v2 protocol
Cordum speaks the Cordum Agent Protocol (CAP) v2, with SDKs in Go, Python, Node.js, and C++. Your agent submits work as a job over a standard wire format and Cordum handles the policy check, approval, and result lifecycle, so there is no framework to adopt and no governance code to maintain in the agent itself.
// Go SDK
job := cap.JobRequest{
Type: "custom.agent.task",
Payload: taskPayload,
Metadata: map[string]string{"user": userId},
}
result, err := cordumClient.Submit(ctx, job)Define policies against any job shape
The Safety Kernel evaluates rules that match on job type, capabilities, risk tags, labels, and other metadata, so the same engine governs a bespoke agent as cleanly as a framework one. Constrain a web-scraping capability to approved domains and require human approval before a deploy agent runs, all from a version-controlled, hot-reloaded policy bundle.
rules:
- name: web-scrape-constraints
match:
capabilities: [web-scrape]
action: ALLOW_WITH_CONSTRAINTS
constraints:
domains: ["*.gov", "*.edu"]
- name: deploy-approval
match:
labels:
agent: deploy-agent
action: REQUIRE_APPROVALHandle approvals with SDK helpers
When a job returns REQUIRE_APPROVAL, the CAP SDK gives you helpers to wait on the decision, apply a timeout, and react to a denial, so you do not have to build the pause-and-resume plumbing yourself. Approvals are bound to the policy snapshot that produced them, so a later policy change cannot silently widen what was approved.
Get an audit trail for free
Every job Cordum governs produces a structured run timeline recording the policy decision, matching rule, approval record, and outcome. You inherit a consistent, queryable audit trail across the whole fleet without writing per-agent logging.
Custom Agents native vs Cordum governance
| Area | Custom Agents Native | With Cordum |
|---|---|---|
| Policy | If-statements | Declarative, hot-reloaded |
| Approvals | Custom per agent | Standard with routing |
| Audit | Custom logging | Automatic timeline |
| Consistency | Self-governed | One policy bundle |
| SDKs | N/A | Go, Python, Node, C++ |
FAQ
What if my agent uses no framework at all?
That is the primary use case. CAP v2 has no framework dependency, so any process that can submit a job over one of the SDKs can be governed, whether it is a single script or a bespoke orchestration layer you wrote in-house.
How do I migrate off homegrown governance?
Start with your highest-risk agents and route just those through Cordum first. You can run the old path and the governed path in parallel during the cutover, then retire the hand-rolled if-statements once the policy bundle covers the same cases.
Which SDK should I use?
Match the SDK to the language your agent already runs in. Cordum publishes Go, Python, Node.js, and C++ SDKs; the Go SDK is the most mature, but all of them speak the same CAP v2 wire format and reach the same Safety Kernel.
Related guides
Ready to govern your Custom Agents agents?
Start with the open-source Cordum platform. Add policies, approvals, and audit trails in minutes.