Why Agent-Built Software Needs a Governed Runtime
AI agents can now write code, modify files, call APIs, generate interfaces, and operate across business systems. That changes the software problem. The hard part is no longer only whether an agent can build something. The hard part is whether the system it builds can be governed, inspected, and trusted.
The problem with agent-written code
Most software stacks were not designed for agents.
They were designed for human developers working inside familiar frameworks:
- a backend framework
- a frontend framework
- an authentication layer
- a database layer
- environment variables
- logs
- API clients
- permissions
- deployment scripts
- monitoring tools
That structure works when experienced humans are responsible for every architectural decision.
It becomes more fragile when agents start writing and modifying the system.
An agent can generate a checkout page. It can write a database query. It can wire a payment provider. It can build an admin dashboard. It can add a support workflow.
But each new capability introduces a governance question:
- What is the agent allowed to read?
- What is it allowed to write?
- Which API key is it using?
- What can that key do?
- Which state transition is legal?
- What action was taken?
- Who approved it?
- Was it logged?
- Can it be audited later?
Traditional codebases can answer those questions, but usually only after inspecting many files, libraries, services, dashboards, logs, and configuration layers.
That is the problem.
Agent-written software does not only need code generation.
It needs runtime governance.
Code generation is not enough
The first wave of AI software development has focused on writing code faster.
That matters.
But speed alone is not enough for operational software.
A faster path to ungoverned code is still ungoverned code.
If an agent writes a JavaScript function that can query arbitrary customer records, the problem is not whether the function works. The problem is that the capability may exist without a clear boundary.
If an agent wires a payment API directly, the problem is not only whether checkout succeeds. The problem is whether the credential is scoped, whether the action is logged, whether refunds are permissioned, and whether the lifecycle is auditable.
If an agent adds a database mutation, the problem is not only whether the mutation passes tests. The problem is whether the write path is allowed by the system model.
This is why agent-built software needs more than code completion.
It needs a governed execution model.
The runtime has to know who is acting
In most applications, code executes because a route, function, job, or handler was triggered.
That is not enough for agentic systems.
The runtime should know the actor.
That actor may be:
- a human user
- an admin
- a support agent
- a commerce agent
- a fulfillment agent
- a compliance reviewer
- an external system
- a scheduled job
Each actor should have an identity.
Each action should be attributable.
Each privileged capability should be scoped.
That means the runtime should not only ask, “Can this code run?”
It should ask:
Who is acting, what are they trying to do, what are they allowed to access, which credential are they using, and what must be logged?
That is the core shift.
API keys should be governed resources
In many software systems, API keys are treated as environmental configuration.
They sit in .env files, secrets managers, CI/CD settings, or cloud dashboards. The application code then uses those keys through libraries and SDKs.
That is common, but it is not enough for agentic systems.
When agents can initiate actions, credentials need to become governed runtime resources.
A payment key should not be a generic secret.
It should have identity, scope, ownership, and logs.
For example:
key stripe_refund_limited:
provider stripe
allow refund.create
used_by RefundAgent
audit required
That declaration is more than configuration.
It tells the system:
- which provider the key belongs to
- what the key can be used for
- which agent may use it
- whether usage must be audited
This is the right abstraction for agent-built software.
The model should never need raw access to the secret. The agent should request a capability, and the runtime should decide whether that capability is allowed.
No raw secrets to models
A governed runtime should follow a simple principle:
Agents should use capabilities, not raw secrets.
That means the agent does not need to see the underlying Stripe key, email provider token, database password, warehouse API credential, or internal service secret.
The agent should be allowed to request actions from a bounded capability surface.
For example:
action refund_customer:
actor RefundAgent
key stripe_refund_limited
require order.status == "paid"
transition OrderFlow: paid -> refund_pending
audit required
The agent can request refund_customer.
The runtime enforces:
- actor identity
- key scope
- order status
- legal transition
- audit logging
That is a safer model than giving the agent broad tool access and hoping instructions prevent misuse.
State machines should be first-class
Operational software is full of lifecycle rules.
Orders are placed, paid, packed, shipped, delivered, refunded, or disputed.
Approvals are drafted, submitted, reviewed, accepted, rejected, or escalated.
Inspections are opened, assigned, performed, reviewed, closed, or reopened.
Deployments are staged, approved, released, monitored, rolled back, or locked.
In conventional software, those lifecycles are often scattered across database fields, route handlers, business logic, and UI conditions.
In agent-built software, that is too fragile.
The lifecycle should be declared directly.
machine OrderFlow:
placed -> paid
paid -> packed
packed -> shipped
shipped -> delivered
paid -> refund_pending
refund_pending -> refunded
Now the runtime has a legal map.
An agent cannot silently skip from placed to refunded unless that transition exists.
A human reviewer can inspect the lifecycle without reconstructing it from application code.
This is what governed software needs.
Audit should not be bolted on later
Many systems treat audit logging as an afterthought.
First the app is built. Then logs are added. Then compliance requirements arrive. Then the team tries to reconstruct who did what, when, and why.
That model does not fit agentic software.
If agents are going to operate systems, audit must be native.
A governed runtime should log:
- actor
- action
- resource
- credential ID
- permission decision
- previous state
- next state
- timestamp
- request context
- approval context where required
For higher-trust environments, the audit log should be tamper-evident.
audit:
hash_chain true
log actor, key_id, action, resource, before, after, timestamp
This makes the system inspectable after execution, not just before execution.
That matters for internal operations, customer trust, regulated workflows, and enterprise adoption.
Default-deny should be the baseline
Agentic systems should not start from broad permissions.
They should start from denial.
If a capability is not declared, it should not run.
If a data read is not allowed, it should not happen.
If a credential is not assigned, it should not be usable.
If a state transition is not legal, it should fail.
If an action requires audit, it should not execute silently.
That default-deny model is critical because agents can be productive and unpredictable at the same time.
A governed runtime does not assume the agent will always choose correctly.
It narrows the action surface so the agent can operate productively inside defined boundaries.
Human inspection still matters
Agent-built software does not eliminate human review.
It changes what humans should review.
Humans should not have to inspect thousands of lines of framework glue just to understand whether a refund workflow is safe.
They should be able to inspect the governing source:
agent RefundAgent:
can read orders
can run refund_customer
cannot read payment_method_raw
key stripe_refund_limited:
provider stripe
allow refund.create
used_by RefundAgent
audit required
machine OrderFlow:
paid -> refund_pending
refund_pending -> refunded
That source tells the reviewer the important things:
- the agent exists
- the agent has bounded permissions
- the key is scoped
- raw payment data is blocked
- the refund action is governed
- the order lifecycle is explicit
This is the inspection surface humans need.
Why ProxyCore exists
ProxyCore exists because agent-written software needs a runtime that treats governance as a foundation, not a plugin.
ProxyLang gives agents and humans a compact source surface.
ProxyCore gives that source surface execution discipline.
The relationship is simple:
ProxyLang
-> compact operational source
ProxyCore
-> governed runtime execution
ProxyLang is what agents write and humans inspect.
ProxyCore is what enforces identity, permissions, state, actions, credentials, and audit.
That separation matters.
The language should stay readable.
The runtime should carry the heavy control logic.
This is not just low-code
Low-code platforms usually optimize for speed of assembly.
ProxyCore is solving a different problem.
The question is not only:
How fast can someone build an app?
The better question is:
Can an agent build and operate software while every important action remains identity-bound, permissioned, state-checked, and auditable?
That is a different category.
ProxyCore is not only a builder.
It is a governed execution substrate for agent-built systems.
The security claim should be precise
No serious platform should claim that leakage is impossible.
Infrastructure can be misconfigured. Adapters can be written badly. Logs can capture too much. Humans can grant broad permissions. Prompt injection can influence model behavior. Dependencies can be compromised.
The right claim is more precise:
ProxyCore is designed so there is no ungoverned execution path by default.
That means the system is built around control points:
- no raw secrets to models
- no arbitrary SQL by default
- no arbitrary network calls by default
- no undeclared tool use
- no unlogged privileged action
- no state transition outside the declared machine
- no capability without actor identity
- no actor without permission scope
This does not eliminate all risk.
It gives the runtime a structure for containing risk.
That is the practical security advantage.
The Day 1 thesis
The first era of software was human-written code.
The second era added cloud platforms, APIs, and automation.
The next era is agent-built operational software.
That era needs a different foundation.
It needs software that is compact enough for agents to modify, explicit enough for humans to inspect, and governed enough for companies to trust.
That is the role of ProxyCore.
The one-line takeaway
Agent-built software cannot rely on code generation alone.
It needs a governed runtime where every actor, credential, action, data access, and state transition is controlled by default.
Or shorter:
Agents should write the system. ProxyCore should govern the execution.