Knowing which agents ran is useful. Being accountable for what they changed requires evidence that follows the work into production. A session record can tell you what an agent attempted without establishing that the right checks ran or that the change improved anything.
This week’s announcements make that distinction harder to ignore. GitLab is bringing external agent activity into its governance dashboard. GitHub is adding detail to usage reporting, with peer comparisons to help leaders interpret their adoption numbers. OpenAI published findings from adversarial testing of its own training infrastructure.
I welcome all three. They also raise the standard for what we’re building with CTOsphere at O’Side Systems. Collecting activity across tools has value, but the harder work is connecting that activity to enforced controls and accepted outcomes.
The audit trail has to follow the change
GitLab’s October 20 announcement brings Duo and connected Claude Code, Cursor, and Codex sessions into one governance view. It also supports session evidence downloads and event streaming. External session capture requires setup, and audit storage is off by default. The record therefore depends on coverage being enabled and maintained. GitLab’s announcement
GitLab also documents tool policies enforced at execution time. Those are real controls. The question for a team using several platforms is how those controls connect to the rest of its delivery process. GitLab’s governance documentation
Take one agent-assisted change. A session log might show a test command being invoked, while CI holds the result for a particular commit. The deployment system identifies what reached production. Someone still has to establish that these records describe the same change, under the policy that actually applied.
That connection is where I’d start an assessment. I’d want evidence for who authorized the run and which identity executed it. I’d check whether the tested commit matches the delivered change, then look for any gap between the permissions requested and those actually granted.
CTOsphere records run policy and authorization, along with the executing identity. It checks an agent’s completion claim against CI on the exact commit pushed and distinguishes the authenticated pusher from the committer recorded in the commit. It also records what the agent read and ran, and exports a self-contained evidence bundle per change.
CTOsphere will add requested-versus-effective policy to that record. A configured restriction and an enforced restriction need separate evidence. Where the record is incomplete, the missing evidence should be visible to the person making the decision.
Adoption needs an outcome attached to it
GitHub’s October 22 usage update names custom skills, agents, MCP servers, and other customizations that previously appeared under generic categories. GitHub says client telemetry can undercount activity and recommends using these metrics for trends and adoption rather than exact accounting. GitHub’s usage metrics release
The Copilot impact dashboard also adds opt-in peer comparisons for agent adoption and relative pull request merge rates. Rankings depend on enough organizations participating. That’s useful context, provided leaders understand who is represented in the comparison. GitHub’s industry comparison release
A higher merge rate still leaves several questions open. Changes can merge faster while creating more rework for other engineers. Review queues can grow too. Neither metric, by itself, tells you what happened to reliability after deployment.
I’d use a usage report to choose what to investigate. If one configuration produces twice as much rework as another, that’s worth examining even if it’s the most popular configuration in the organization. The comparison also needs to account for task difficulty. A tool assigned the hardest work can look worse in a simple ranking.
CTOsphere connects agent runs to accepted, rejected, or reworked outcomes, with model usage and dollar cost attached. It records human changes after handoff and tracks review findings through their disposition. That lets teams examine the cost of an accepted change and the effort spent resolving review findings.
CTOsphere will attach a configuration fingerprint to each run, identifying the model and the skills and servers involved. It will evaluate runs against the organization’s declared acceptance criteria. Teams will be able to compare configurations using their own definition of acceptable work.
The measure I care about includes the effort left for people. A lower model bill doesn’t help much if engineers spend the savings repairing the output.
Containment needs to be tested where the agent runs
OpenAI’s October 23 disclosure describes adversarial testing. The exercises targeted copies of its internal training and evaluation infrastructure. Agents found sandbox escapes, indirect routes to the internet, and ways to communicate across isolation boundaries. OpenAI says it remediated the discovered weaknesses. These were deliberately adversarial research conditions, distinct from ordinary customer use. OpenAI’s account
The engineering lesson is to test the boundaries you depend on. A permitted service can become an indirect route to something blocked. Shared infrastructure can introduce communication paths that aren’t obvious from an individual workspace’s settings.
I’d still start with the sandboxing the platform provides. Building a replacement introduces another system to maintain and defend. The next step is to test the restrictions in the environment where the agent actually operates.
Suppose a run is allowed to reach two hosts and use one repository credential. The evidence should show which restrictions were active and what happened when tests attempted prohibited access. It should identify the tested environment closely enough to tell when a later configuration change makes those results stale.
CTOsphere scopes code-host credentials to the repository for the run and records the credential class used. It enforces workspace isolation across tenants and includes negative conformance tests that exercise declared restrictions. Those results establish how the controls behaved under the tested conditions.
CTOsphere will run containment probes inside the effective execution environment for each configuration. These will cover indirect internet access, credential reachability, cross-job leakage, and interference with monitoring. Results will be tied to that environment, so the record shows what was tested and what happened.
Passing a test doesn’t establish that every possible escape has been eliminated. It gives the team evidence to inspect and a basis for repeating the tests as the environment changes.
Start with one change you already shipped
Pick one agent-assisted change from the last 30 days. Collect what your existing tools show, then trace it through approval and CI to deployment. Write down the claims you can substantiate and the evidence you couldn’t find.
That’s how I’d begin the comparison with CTOsphere. The missing records give us a concrete scope for the work. They also help separate an integration problem from a control that was never defined or tested.
O’Side Systems delivers CTOsphere through a hands-on implementation alongside your existing engineering tools. We’ll connect the evidence and leave you with a record you own, along with documented results for the controls we’ve tested. If your existing platform already supports the claims you need to make, we’ll tell you that too.
Get in touch if you’d like to work through one of your changes. Start with the evidence your organization needs to stand behind, then decide which tooling is missing.