Code Governance

Concept page. This explains how AxonFlow inspects model-generated code and records what it finds. Code governance is a detection-and-audit layer: it attaches metadata to governed responses so you can see and review generated code. For the enforcement primitives it builds on, see Policy-as-Code and Audit Logging.

Code governance is the part of AxonFlow that treats model-generated code as something to inspect, not just something to display. If your assistants write SQL, Python, TypeScript, shell commands, Terraform, or infrastructure snippets, you need visibility into that output before it quietly becomes part of your systems.

AxonFlow does that by attaching code metadata to governed responses. Instead of only returning the model output, it can also tell you:

whether the response contains code
which language it looks like
what kind of artifact it is
how large it is
whether potential secrets or unsafe patterns were found

That makes code governance useful for both engineers building internal coding agents and platform teams reviewing how those agents behave over time.

What Gets Recorded

When AxonFlow detects code in a response, the policy metadata can include a code_artifact object:

{
  "policy_info": {
    "code_artifact": {
      "is_code_output": true,
      "language": "python",
      "code_type": "function",
      "size_bytes": 245,
      "line_count": 12,
      "secrets_detected": 0,
      "unsafe_patterns": 1,
      "policies_checked": ["code-secrets", "code-unsafe", "code-compliance"]
    }
  }
}

These fields line up with the public SDKs:

Field	Meaning
`is_code_output`	Whether the response contains code
`language`	Detected language such as Python, Go, SQL, or TypeScript
`code_type`	Function, class, script, config, snippet, or module
`size_bytes`	Approximate size of detected code
`line_count`	Number of code lines
`secrets_detected`	Count of potential secrets found
`unsafe_patterns`	Count of risky constructs found
`policies_checked`	Code-governance detector categories that were applied

policies_checked lists the detector categories that ran (for example secret detection and unsafe-pattern detection), not separately-toggled policy rules. Treat these as the code-inspection categories behind the metadata above.

Why This Matters In Practice

Code generation is one of the fastest ways teams get value from LLMs, and one of the fastest ways they accumulate hidden risk.

Common failure modes include:

an assistant generating SQL that selects more data than needed
a code helper suggesting eval, shell execution, or deserialization shortcuts
a support or ops workflow returning infrastructure snippets with embedded credentials
a developer tool producing patches or scripts that look helpful but violate internal guardrails

Code governance helps you see and govern that behavior without forcing every generated snippet through a manual review process.

Supported Languages And Artifacts

AxonFlow detects code across the common languages and configuration formats teams actually use in AI workflows:

Language or format	Common examples
Python	functions, classes, scripts
Go	packages, structs, helper functions
TypeScript / JavaScript	interfaces, handlers, client code
Java	classes, methods, service snippets
SQL	query generation, schema inspection, reporting logic
Bash	operational scripts and command sequences
YAML / JSON	agent config, workflow config, deployment manifests
Dockerfile / Terraform	infra and deployment automation

The artifact type is also categorized so teams can distinguish a small snippet from something that looks like a full module or executable script.

What Counts As A Risk Signal

Code governance does not magically prove code is safe. It gives you structured signals that let you decide where to inspect more closely.

Secret-Oriented Signals

Potential secret patterns can include:

API keys and tokens
private keys
bearer tokens
credentials embedded in connection strings
obvious password assignments

Unsafe Pattern Signals

Common unsafe patterns include constructs such as:

shell execution helpers
unsafe deserialization paths
direct HTML injection patterns
runtime code execution primitives
infrastructure settings that look privilege-heavy

The important design point is that these are governance signals, not just lint-style decorations. They can inform audit records, downstream review, and policy actions.

Using Code Governance In The SDK

Python

from axonflow import AxonFlow

async def main():
    async with AxonFlow(
        endpoint="http://localhost:8080",
        client_id="platform-team",
        client_secret="replace-me",
    ) as client:
        response = await client.proxy_llm_call(
            user_token="developer-123",
            query="Write a Python helper that loads YAML config and validates it",
            request_type="chat",
        )

        if response.policy_info and response.policy_info.code_artifact:
            artifact = response.policy_info.code_artifact
            print("language:", artifact.language)
            print("type:", artifact.code_type)
            print("unsafe patterns:", artifact.unsafe_patterns)

TypeScript

import { AxonFlow } from '@axonflow/sdk';

const client = new AxonFlow({
  endpoint: 'http://localhost:8080',
  clientId: 'platform-team',
  clientSecret: 'replace-me',
});

const response = await client.proxyLLMCall({
  userToken: 'developer-123',
  query: 'Write a TypeScript helper for validating customer profile payloads',
  requestType: 'chat',
});

if (response.policyInfo?.codeArtifact) {
  const artifact = response.policyInfo.codeArtifact;
  console.log(artifact.language, artifact.code_type, artifact.unsafe_patterns);
}

Both examples use the current public proxy-mode path rather than older executeQuery() examples that no longer represent the preferred API surface.

How Teams Usually Apply It

The most practical uses tend to be:

logging and inspecting generated code in internal developer assistants
watching for risky output from data and operations agents
flagging unsafe patterns before generated code reaches pull requests, tickets, or runbooks
measuring whether a team’s coding agents are getting safer or riskier over time

This is also a place where Community is genuinely useful on its own. A staff engineer can build a governed coding workflow locally, inspect code artifacts in responses, and decide whether stronger review and enterprise integrations are worth adding later.

Community, Evaluation, And Enterprise

Capability	Community	Evaluation	Enterprise
Code artifact detection in responses	✅	✅	✅
Secret and unsafe-pattern counts	✅	✅	✅
Audit-oriented response metadata	✅	✅	✅
Simulation and evidence workflows around governed code	❌	✅	✅
Richer operating surfaces and enterprise review workflows	❌	❌	✅
Git-provider and pull-request operating features	❌	❌	✅

That split is useful commercially and technically:

Community proves the governance signals are real.
Evaluation helps teams test those signals against broader governance workflows.
Enterprise is where teams usually land once code generation becomes shared infrastructure and needs a stronger operating model.

Enterprise Pull Request Workflow

The licensed code-governance surface turns model-generated code into auditable pull-request workflows with provider configuration, PR records, metrics, and exports.

Enterprise code governance is the AxonFlow surface for turning model-generated code into auditable pull-request workflows. It is designed for teams that want AI-assisted development without giving up repository controls, review processes, or traceability.

The enterprise value here is not only “create a PR from code.” It is being able to answer:

which tenant created it?
which provider was used?
how many files changed?
were secrets or unsafe patterns detected?
what happened to the PR afterward?

What The Enterprise Surface Includes

Current enterprise code-governance routes:

Method	Path	Purpose
`GET`	`/api/v1/code-governance/prs`	list PR records
`POST`	`/api/v1/code-governance/prs`	create a PR from generated code
`GET`	`/api/v1/code-governance/prs/{id}`	fetch one PR record
`DELETE`	`/api/v1/code-governance/prs/{id}`	close a PR record
`POST`	`/api/v1/code-governance/prs/{id}/sync`	sync PR state from provider
`GET`	`/api/v1/code-governance/git-providers`	list configured provider records
`POST`	`/api/v1/code-governance/git-providers`	configure a provider
`POST`	`/api/v1/code-governance/git-providers/validate`	validate credentials before saving
`DELETE`	`/api/v1/code-governance/git-providers/{type}`	delete configured provider
`GET`	`/api/v1/code-governance/metrics`	tenant metrics
`GET`	`/api/v1/code-governance/export`	export governance records

Authentication Model

These are enterprise portal APIs. In normal enterprise usage, requests arrive with session-backed tenant context rather than raw public bearer tokens.

The handlers derive the effective tenant from:

session context first
header fallback where supported internally

That is why the docs and examples for this surface should use the enterprise portal model rather than older localhost and X-Org-ID only examples.

Supported Git Providers

The current enterprise code-governance implementation supports:

GitHub
GitLab
Bitbucket

Provider configuration can include:

type
token
base_url
app_id
installation_id
private_key

That covers hosted and self-managed Git provider patterns without forcing every enterprise into the same auth model.

Configure A Provider

curl -b cookies.txt \
  -H "Content-Type: application/json" \
  -X POST https://portal.example.com/api/v1/code-governance/git-providers \
  -d '{
    "type": "github",
    "token": "ghp_redacted"
  }'

Validate credentials before saving:

curl -b cookies.txt \
  -H "Content-Type: application/json" \
  -X POST https://portal.example.com/api/v1/code-governance/git-providers/validate \
  -d '{
    "type": "github",
    "token": "ghp_redacted"
  }'

One practical detail from the current implementation: the list API returns the configured provider inventory for the tenant, but the current service model is much closer to “one active provider configuration per tenant” than an unrestricted multi-provider management console.

Create A Pull Request From Generated Code

The PR creation request includes both repository instructions and governance metadata:

{
  "owner": "acme",
  "repo": "customer-platform",
  "title": "Add governed travel approval handler",
  "description": "Implements approval routing for regulated travel requests",
  "base_branch": "main",
  "branch_name": "feature/travel-approval",
  "draft": true,
  "agent_request_id": "req_123",
  "prompt": "Add an approval handler for travel escalations",
  "model": "claude-sonnet-4",
  "policies_checked": ["code-secrets", "code-unsafe"],
  "secrets_detected": 0,
  "unsafe_patterns": 0,
  "files": [
    {
      "path": "internal/approval/handler.go",
      "content": "package approval\n"
    }
  ]
}

Important tracked fields in the stored PR record include:

tenant ID
provider type
repository and PR number
head and base branch
file count
secrets detected
unsafe patterns
created, merged, and closed times

Metrics And Export

GET /api/v1/code-governance/metrics returns tenant-level aggregates such as:

total PRs
open PRs
merged PRs
closed PRs
total generated files
total secrets detected
total unsafe patterns
first and last PR timestamps

GET /api/v1/code-governance/export supports:

format=json|csv
start_date
end_date
state

That export is especially useful for internal SDLC governance reviews and regulated engineering environments where AI-generated changes need traceable reporting.

How It Connects To Policy Management

Code governance gets much stronger when it is paired with:

system policies in code-secrets, code-unsafe, and code-compliance
tenant or organization policies that escalate risky code-generation flows
HITL approval paths for sensitive repositories or protected branches

That is the pattern that turns AI coding from a convenience feature into a production software-delivery control plane.

Recommended Rollout

Configure and validate a provider.
Start with draft PRs.
Track secrets and unsafe-pattern counts aggressively.
Add review or approval gates for sensitive repositories.
Export and review code-governance data with platform and security stakeholders.

Audit Logging for storing the evidence trail around governed requests
Policy Overview for policy authoring and enforcement
Cost Management if code-generating agents need budget controls
Policy Simulation & Impact Report for testing policy changes before rollout

Rollout Checklist

Use this page as one layer of the broader governance rollout:

decide where the rule belongs with Policy Hierarchy
test the request path with Runtime Request Paths
connect review workflows to HITL Approval Gates when a block should become a human decision
compare Community vs Evaluation vs Enterprise when simulation, evidence export, SSO, SCIM, or portal operations become requirements

What Gets Recorded​

Why This Matters In Practice​

Supported Languages And Artifacts​

What Counts As A Risk Signal​

Secret-Oriented Signals​

Unsafe Pattern Signals​

Using Code Governance In The SDK​

Python​

TypeScript​

How Teams Usually Apply It​

Community, Evaluation, And Enterprise​

Enterprise Pull Request Workflow​

What The Enterprise Surface Includes​

Authentication Model​

Supported Git Providers​

Configure A Provider​

Create A Pull Request From Generated Code​

Metrics And Export​

How It Connects To Policy Management​

Recommended Rollout​

Related Documentation​

Rollout Checklist​