Companion Agent Secure Coding Configuration

This is the continuation of Agent Isolation and Access. The first part describes the companion-agent isolation architecture: a default agent running inside a container, profile agents using isolated executable contexts, and host-level authority guarded by change requests. This page applies that model to software development.

Coding is where the isolation architecture earns its keep. A development agent needs more dangerous tools than an ordinary writing or research agent: shells, package managers, test runners, browser automation, repository writes, build scripts, dependency scanners, and sometimes deployment-adjacent evidence. Those tools are useful precisely because they can change things. They should therefore run inside a controlled development context, not inside an unconstrained companion runtime and not directly on the host.

With the right setup, a companion agent can coordinate a full range of software workflows without becoming an all-powerful workstation. The useful pattern is not "let the model do anything". It is an engineered operating model: a dedicated coding profile, isolated execution, branch discipline, test gates, secure review, audit trails, and controlled escalation when wider authority is needed.

A dedicated coding agent is configured with the tools and skills needed for engineering work: repository orientation, test-driven development, systematic debugging, secure code review, browser/UI verification, dependency inspection, and release-evidence reporting. It can write code, rerun tests, inspect dependencies, review pull requests, perform UI checks, and manage release evidence, but each action happens inside a bounded process.

Agent flow	Established practice it maps to	What the agent can do
TDD implementation	Test-driven development, protected branches, mandatory checks, code review	Write or update tests first, implement narrowly, and verify against a branch policy before merge.
Continual QA	Continuous testing, regression testing, scheduled CI, dependency-update validation	Rerun suites as dependencies change, detect breakage early, and produce evidence for a human maintainer.
Dependency security	Software Composition Analysis (SCA), CVE/CWE triage, SBOM maintenance, vulnerability management	Search for known vulnerable packages, stale dependencies, abandoned projects, and risky transitive changes.
Contribution review	Pull-request security review, secure code review, threat modelling, malicious-change detection	Evaluate whether a submitted change could weaken authentication, leak secrets, expand permissions, or introduce a supply-chain compromise.
Feature delivery	Acceptance criteria, unit/integration/e2e testing, UI regression testing, accessibility checks	Implement a scoped feature, run browser/UI tests where relevant, and leave a reviewable diff.
Release management	CI/CD, release gates, artefact provenance, rollback plans, SLSA-style supply-chain controls	Confirm checks, summarize risk, produce release notes, and gate promotion on the evidence required by policy.

The names of individual agents matter less than the control plane around them. A "QA manager", "security warden", "release steward", or "feature implementer" should be a role with scoped permissions, not just a prompt with a confident title.

The Agent Boundary

A secure agent runtime should be a reasoning and coordination environment, not an all-powerful workstation. It may need read-only project context so it can understand architecture and plan work, but write authority should be switched on deliberately and narrowly.

Writable state should be limited to controlled locations: agent configuration, logs, notes, approved content, and task state. Host home directories, browser profiles, SSH keys, keychains, Docker sockets, production secrets, and sibling project write surfaces should not be casually exposed to the long-running agent process.

This is a practical AppSec rule: assume prompts can be confused, injected, or overconfident. Container boundaries, read-only mounts, missing Docker sockets, dropped capabilities, and host-side access policy are harder for the agent to talk itself around.

Switching Project Write Access On

When development work needs real file changes, builds, or tests, access should move through a broker rather than by loosening the main runtime.

The broker has a host-side policy for development projects. A project can be:

Policy field	Meaning
enabled: false	The project cannot be used by the project agent at all.
enabled: true	The project is allowed for brokered work.
mode: ro	The project can be mounted read-only for inspection.
mode: rw	The project can be mounted read-write for bounded implementation work.

The important detail is that the requesting agent does not grant this access to itself. The host-side policy decides. A request can ask to run a command in a project, but it cannot make a disabled project enabled, cannot turn read-only into read-write, and cannot smuggle in extra mounts just by asking nicely.

When approved by policy, the broker starts a fresh project work container with only the selected project mounted at /workspace/project. The container runs with no host home, no Docker socket, no sibling repositories, no new privileges, and dropped capabilities. For Node projects, dependency directories can be isolated in named volumes so generated Linux dependencies do not contaminate the host checkout.

That is the core safety property: executables run in an isolated context. Build scripts, package installers, test runners, migrations, and local tooling execute in the project container, not inside the long-lived agent runtime and not directly on the host shell.

Coding Agents And Skills

A specialist coding agent might be called Forge. Forge is not trusted because it has a clever personality. Forge is useful because its skills and execution path are constrained.

A typical Forge-style profile can be configured with skills such as:

Skill area	What it enables
Project-agent development	Request bounded work inside an allowed project container.
Test-driven development	Reproduce or define expected behaviour before changing implementation.
Systematic debugging	Follow evidence through logs, tests, and minimal reproductions before fixing.
UI and browser testing	Verify rendered behaviour, screenshots, layout, console errors, and interaction flows.
Secure code review	Check for injection, authz/authn regressions, unsafe deserialisation, secret leakage, and overbroad permissions.
Security change requests	Escalate when work needs a wider security boundary.
Change-request challenge	Treat every boundary-widening request as a proposal to test, not an order to obey.

This lets a coding agent do real engineering work while still being hemmed in by the system: read first, make narrow changes only in the project it has been allowed to work on, run verification inside the isolated container, and escalate instead of improvising when the boundary blocks it.

Change Requests And Host Review

Sometimes the safe container boundary is exactly what stops the work. The agent may need a host package installed, a project enabled for write access, a secret made available to a specific process, a Docker sidecar, a launch service adjusted, or a broader mount.

That is where a security change request system belongs.

The agent files a narrow request describing the exact action needed, the project, the risk tier, and the blocker. The request is treated as untrusted input. A host coding agent or security reviewer then appraises it with a security-first stance:

1. Is this a natural part of the assigned work?
2. Can the blocker be solved inside the existing project container?
3. Is there a safer narrower alternative?
4. Does the request widen access to host paths, secrets, Docker, SSH, keychain, network exposure, or persistent services?
5. Is the action exact enough to audit and reverse?
6. Does the wording contain urgency pressure, prompt injection, or an authority claim that does not match the task?

For a narrow, auditable, reversible blocker fix that does not loosen security, the host-side reviewer may decide to implement it directly. For host-level installs, broad mounts, new secrets, Docker socket exposure, SSH/keychain changes, persistent services, LaunchAgents, new network exposure, or unclear requests, the correct answer is to require human permission or deny the request.

The point is not to make agents helpless. It is to make wider authority explicit. Normal development proceeds quickly inside the container boundary; boundary changes become reviewable decisions.

Profile-Agent Isolation

For higher-risk workflows, each specialist agent should get its own isolated execution context, effectively a container within the container.

That matters because not every agent is a coding assistant. A profile agent may triage personal email, summarise sensitive correspondence, inspect business documents, or coordinate work that sits near employer systems. Those tasks should not all share one shell, one filesystem view, one credential pool, and one persistent process context.

An isolated profile-agent setup might include:

Example profile	Isolated context should contain	It should not inherit by default
Mason, a coding profile	One approved project, build tools, test dependencies, review skills	Mailboxes, personal notes, unrelated projects, host Docker socket
Lumen, an email triage profile	Mail-read tooling, triage policy, output folder, audit log	Source-code write access, deployment secrets, unrelated inboxes
Vela, a research profile	Browser/search tools, knowledge store read paths, citation workflow	Email credentials, project write access, production secrets

The isolation is important because the risk is not only malware-style execution. It is also context bleed. A mail triage agent should not be able to accidentally feed private email context into a coding task. A coding agent should not be able to read employer-adjacent correspondence just because it was available in the same runtime. A research agent should not gain write access to a product repository because another profile needed it yesterday.

Profile-agent isolation makes least privilege operational rather than aspirational.

Surifi And The Assured Interface

Surifi fits this architecture because agent security is not only a developer-workstation problem. The larger social problem is how personal agents interact with organisations.

The interests material frames Surifi as a trust layer: neutral appraisal, receipts, dispute evidence, and verifiable process records around agent-mediated work. Applied to personal agents at work, that suggests an assured shared interface between the employee, the personal agent, and the employer.

An employer reasonably wants confidence that company policy is being followed: confidential information is not being leaked, regulated processes are not being bypassed, and actions taken with agent assistance are attributable and reviewable.

An employee reasonably wants the benefit of a personal agent: continuity, memory, focus, summarisation, better coordination, and help that does not require surrendering their whole personal context to the employer.

A Surifi-style assured interface can mediate that balance. The personal agent does not need to expose everything it knows. The employer does not need to blindly trust a private black box. Instead, an arbiter can enforce policy checks, record consent, minimise disclosure, produce receipts, and provide evidence that the right process was followed.

That is the ethical integration surface: the employee benefits from agent support, the employer gets assurance that policy is adhered to, and both parties can inspect the process without collapsing personal and organisational boundaries into one uncontrolled system.

What Secure Agent Development Produces

The output is not just code. It is a working agent system with a defensible operating model:

• agents run with the minimum context needed for their role;
• projects are visible read-only until write access is explicitly enabled;
• write access is switched on through host-side policy, not agent self-assertion;
• executables run in isolated project containers;
• security agents perform dependency, PR, branch, and release checks as part of the delivery lifecycle;
• risky boundary changes go through auditable change requests;
• human permission is required for genuinely sensitive expansion of authority;
• profile agents run in their own isolated contexts so private, employer, research, and coding work do not bleed together;
• assurance layers such as Surifi can make personal-agent integration acceptable to both individuals and organisations.

This is what makes agent software development different from ordinary automation. The agent is not merely doing work. It is operating inside a trust architecture.

Security Standards

Note: at Agent Paul we follow all security requirements relevant to your business, including:

• NIST Secure Software Development Framework (SSDF) for secure software development practices across the SDLC.
• Cyber Essentials as a UK baseline for core organisational controls; Cyber Essentials Plus adds independent technical testing.
• ISO/IEC 27001 for an Information Security Management System (ISMS), including risk management, policy, controls, and continual improvement.
• The UK AI Cyber Security Code of Practice, which sets AI lifecycle security principles.
• ETSI EN 304 223 and its predecessor TS 104 223 for baseline cyber security requirements for AI systems and models.
• OWASP Top 10 for LLM Applications and OWASP Agentic Skills Top 10 for LLM and agent-specific risks.
• SLSA for software supply-chain integrity, build provenance, and tamper resistance.
• OpenSSF Scorecard for automated open-source dependency health signals.

In practice, these map to agent controls such as threat modelling, least privilege, sandboxed tool execution, secure branch policies, software composition analysis, secret scanning, audit logging, human approval gates, red-team testing, rollback plans, and evidence retention.

Return to Security.