The conversation about AI agent security is becoming more concrete. The newly formed Blueprint Alliance brings together major cloud, security and software companies around an open reference architecture for securing enterprise AI agents.
That work matters. Agent security has often been discussed as a set of separate problems: identity, permissions, tool access, prompt injection, monitoring and audit logs. The Blueprint brings many of those concerns into a common lifecycle, asking organisations to know where their agents are, what they can do, what they are doing and how to respond when something goes wrong.
For enterprises deploying autonomous agents, that is important infrastructure. For software development, another question follows:
An agent may be authorised to act. Was it authorised to make this particular software change?
Access to a repository does not define acceptable change
Imagine an AI coding agent working on a payments application. The enterprise knows the agent, has assigned an accountable owner, and has delegated access to the repository for a defined task. Runtime controls allow it to read relevant files and modify source code.
Then the agent decides the task requires changing authentication logic, adding a dependency, modifying the deployment workflow or weakening a security check that is causing a test to fail.
The agent may still be operating inside an authorised session. But the organisation now needs to determine whether that kind of change was permitted, whether policy required human approval, whether the right controls ran afterward and whether the code that reached production is the code those controls evaluated.
Those are questions about governing the software change itself. Repository access and tool permissions alone cannot answer them.
Connect agent security to the software lifecycle
The Blueprint Alliance architecture describes capabilities such as task-scoped access, traceable delegation, guardrails, runtime monitoring, containment and evidence. Software development needs a domain-specific chain that connects those capabilities to the change and its delivery:
Human intent → Agent identity → Runtime authorisation → Proposed change
→ SDLC policy → Actual change → Tests and security controls
→ Human approval → Build artefact → Production deployment → Evidence
Each step answers a different question:
- Identity establishes which agent acted.
- Runtime authorisation establishes what that agent could do in the task context.
- SDLC policy determines whether the proposed change meets engineering and security requirements.
- Provenance connects agent activity to the resulting source change.
- Delivery evidence links that change to the checks, approvals, build and deployment that followed.
Together, these records let an organisation reconstruct not just what an agent could do, but what happened to the software as a result.
Apply policy to the change being proposed
A runtime decision might say: “This coding agent may modify this repository for this task.” Software-change policy can add boundaries specific to the work:
- Changes to payment authentication require human approval.
- New dependencies must come from an approved registry and meet organisational policy.
- The agent cannot modify the production deployment workflow.
- Changes affecting a security control require designated review before they progress.
These controls build on agent identity and runtime authorisation. They do not replace them. Agent security and agentic SDLC governance are complementary layers: one governs an agent’s identity and actions in its environment; the other governs the software changes it proposes and the path those changes take toward production.
Preserve evidence that connects the steps
Blocking an unsafe action is only part of governance. When an action is allowed, an auditor, security leader or incident responder may later need to know:
- Who requested the change, and which agent performed it?
- What authority was delegated, and which policy version evaluated the change?
- What exactly changed, and which controls ran afterward?
- Who approved it, which build contained it, and did that build reach production?
Answers may be spread across agent logs, source control, CI/CD platforms, security scanners, identity systems and deployment tooling. The challenge is preserving the links between them. An organisation can have plenty of logs and still struggle to demonstrate a governed software-development process if the records cannot be connected.
A complementary layer for AI-driven software change
Secuarden is being built to address governance of AI-driven software change: applying policy to what a coding agent is attempting to change, recording the decision and preserving evidence that links the resulting change to the controls and approvals it passes on the way to production.
The goal is not to replace agent identity systems, enterprise authorisation or runtime security platforms. Those systems establish who or what an agent is, what authority it has and whether an action should be permitted in its runtime context. Secuarden focuses on the software-development layer.
In simple terms: Control what AI can change. Prove what it did.
The Blueprint Alliance is significant because it moves the industry toward a shared architecture for enterprise agents. For software engineering, that architecture becomes more useful when agent identity and runtime authorisation connect directly to software-change policy and provenance.
The question then moves beyond “Was this AI agent allowed into the repository?” to a more useful one: Can we prove this agent was allowed to make this particular change—and that the software reaching production passed the controls we require?
That is the question agentic SDLC governance needs to answer.