Challenge
Your engineers already use agents such as Claude Code, Cursor, and GitHub Copilot, on laptops and in CI. An agent on an engineer's laptop can reach everything that engineer can. Your security team needs to know what each agent can reach, who authorised it, and where the record is kept. A ban slows delivery and pushes agent use out of sight; leaving it unmanaged means having no answer when an auditor or customer asks. You need an approved way to run agents on your own estate, with evidence your platform and security teams can inspect.
Approach
We start with the included two-day Agent Readiness Assessment. Together we select two workflows, agree data boundaries and approved tools, and choose the architecture the pilot will start from. We define success in terms of useful output, reviewer effort, cost, and whether the controls hold.
The five-week pilot then builds what the industry is starting to call an agent control plane, on one of your own non-production Kubernetes clusters. Your two workflows run with sandbox isolation, restricted access, and scoped identities. Every pilot task produces a signed record of its authorisation, configuration, and permitted access. Your engineers and operators test the workflows alongside us.
In week four we test 20 failure scenarios, including prompt injection and attempted data exfiltration. You receive the findings, evidence pack, configuration, and runbooks, plus a production recommendation and separate quote. The handover includes a rehearsal of stopping tasks and revoking access.
Our Siemens Digital Industries case study demonstrates our Kubernetes platform delivery experience. For team skills, see AI-Assisted Engineering training and our AI Engineering Principles.
- 5 weeks
- to a governed pilot
- 2
- real workflows on your platform
- 20
- failure scenarios in the pilot
Governed AI Agent Platform Roadmap
Alignment
Two-day workshop
- List agents already in use
- Agree two pilot use cases
- Agree data and model boundaries
Steps
Outcomes
- Agent inventory
- Risk map
Management · Development · Security
- Approved models and hosts
- Pilot success criteria
Management · Infrastructure · Security
Design
Week 1
- Design runtime, egress and identity
- Tailor policy pack with security
Steps
Outcomes
- Target architecture
- Egress allowlist
Infrastructure · Security
- Client policy configuration
Development · Security
Build
Week 2
- Install sandbox runtime on a non-production cluster
- Restrict access and add policy checks
- Onboard first workflow
Steps
Outcomes
- Sandboxed agent runtime
- Runtime network policy
Infrastructure · Operations
- Configuration checks
- Signed task records
Development · Operations · Security
Execute
Week 3
- Onboard second workflow
- Issue an identity per agent
- Configure approved tool access
Steps
Outcomes
- Two agents in governed sandboxes
Development · Operations
- Per-agent workload identity
- Scoped tool access
Infrastructure · Security
Validation & Analysis
Week 4
- Run 20-scenario agent wargame
- Review evidence with security
Steps
Outcomes
- Wargame findings
Infrastructure · Development · Security
- Signed evidence pack
- Control gap register
Management · Security
Completion & Handover
Week 5
- Present findings and recommendations
- Rehearse task stop and revoke
Steps
Outcomes
- Pilot asset handover
- Knowledge sharing
Infrastructure · Development · Operations · Security
- Production build quote
Management
Governed AI Agent Platform FAQ
Chief Information Security Officer
Can we show who authorised a task and what it was allowed to access?
LiveWyer
Solution: A signed record for every agent task
Each task has a signed record of who authorised it, its configured image, approved model and tools, permitted destinations, and policy version. Your team can verify the record. It shows what was authorised; activity logs show what happened during execution. We document the coverage and gaps in both.
Data Protection Officer
Does our code leave our infrastructure?
LiveWyer
Solution: Only to the model providers you approve
Agents run on your cluster and can only reach the systems you approve. When an agent calls a model, the prompt, including any code it contains, goes only to the providers you approve, through an egress allowlist agreed during the readiness assessment. Hosting agent execution yourself does not mean model inference is local. If you need inference in-house as well, we can scope that separately.
Head of Platform Engineering
Why not install an open-source agent runtime ourselves?
LiveWyer
Solution: Controls around the runtime
You can. We bring the work around the runtime: onboarding your workflows, integrating access controls, collecting evidence, and testing how the design fails. We choose the runtime with you, place policy checks where they can be enforced, and hand over a configuration your team can operate.
Engineering Director
Will this slow our teams down or tie us to one vendor?
LiveWyer
Solution: Measured effort and configuration you own
The pilot builds on two workflows your engineers already run, and they test them alongside us. By week five you have measured figures for review effort and operating cost, so you can see any slowdown before deciding on production. You retain the configuration, evidence definitions, and runbooks. Changing runtime later can require integration work and fresh testing.
Discuss your agent workflows
Are you interested in our Governed AI Agent Platform pilot? Book a quick chat with one of our team to find out more.
Discuss your agent workflows