Building an AI-Native Security Workspace

A security engineer rarely works inside one application. A single question — does this endpoint enforce the session boundary it claims? — is answered with a browser, an HTTP history, an editor, a terminal, a scanner and, increasingly, a model. None of those tools is the problem on its own. Each is good at what it does.

The problem is the join between them. Ask where each observation lives once the question has been answered, and the honest answer is: partly in a proxy history, partly in terminal scrollback, partly in a note file, partly in a ticket, and mostly in the engineer's head. The finding survives. The route to the finding usually does not.

That is not a tooling failure so much as an architectural one. Every tool in the chain was designed to be used, not to be part of a record. So the record ends up being maintained by the one component that cannot show it to a reviewer, cannot be searched, and leaves when the engineer changes project.

The shape of the work is stable enough to draw. It is a chain of observations, each produced by a different tool, each depending on the previous one.

Every arrow is a handoff, and each handoff has a cost that is easy to under-count because it is paid in attention rather than in money. The costs are not identical, and naming them separately is what makes them addressable.

• Context switching: each move to another tool carries an entry cost, paid before any work is done.
• Context reconstruction: the engineer re-derives what the previous tool knew, from memory or from a fresh search.
• Tool fragmentation: the answer exists only as the sum of six partial views, and no single tool holds the whole.
• Evidence fragmentation: the transaction, revision or command output that justified a step is not carried forward, so it cannot be re-checked later.
• Knowledge fragmentation: conclusions accumulate in notes and tickets, disconnected from the material that produced them — which is why a second engineer, or the same engineer next month, has no path back through the reasoning.

It is worth being precise about what is not fragmented. The engineer's judgement is not fragmented; it is the strongest component in the chain. What fragments is the record that judgement was applied to. This distinction matters because it determines what a better tool should automate: the retention and movement of context, not the conclusion.

A conversational assistant is a genuinely useful addition to this workflow, and it is not the fix. Its unit of work is a message exchange. The unit of work in security engineering is an investigation that outlives the exchange.

The gap shows up as a table, and it is not subtle.

There is a second, less obvious consequence. Once an assistant can act — drive a browser, run a command, edit a file — the constraint stops being what the model knows and becomes what it is allowed to do and what it leaves behind. Capability questions are answered by model quality. Control and retention questions are not answered by the model at all, because they are properties of the surrounding system.

If the missing layer is the one that binds work to context, permissions and evidence, then it should be designed as a layer rather than improvised inside a conversation. We call it a harness, and give it a narrow definition: the host layer that binds an objective to an environment, to the surfaces that can execute work, to a permission scope, to verification and to recovery.

Two boundaries in that diagram are deliberate. The runtime keeps ownership of the inner loop; the harness never runs a competing one, because two loops making decisions about the same task is how state becomes unreproducible. And the conclusion stays outside the system: the harness can gather, retain and verify, but a finding is still an engineering judgement about impact.

The workspace is the harness's persistent part: everything that must outlive a single turn. That state has several homes. Project files, task activity, captured traffic and selected Spaces retain different kinds of material. Keeping their roles distinct lets a reviewer follow each observation back to the record that supports it.

Task context
├── Project files             code and working artifacts
├── Activity                  actions and execution results
├── Traffic / Request         captures and separate revisions
└── Selected Spaces
    ├── Original sources      source identities and versions
    ├── Local indexes         searchable extracted text
    └── Agents.md navigation  paths back to source material

Spaces retain original material with source identities and versions. A task can use the spaces selected for its project; search returns qualified source locations and line hints, and the agent can open selected evidence. Navigation helps find material, while the original source remains the place to check a factual claim. Saving or queueing a source does not mean its index is ready.

Local indexing makes retained source text searchable. An engineer can explicitly request model-assisted navigation analysis to describe file topics and reading purposes. Those descriptions help the next task choose what to read; the source content and its version remain the evidence to check.

A workspace also defines where a search may go. Project-file access is checked against the registered root; source searches exclude dependency and build directories. Reads and directory walks are bounded, so a large project may require more than one search or read. The engineer needs to know which portion was inspected before treating a result as complete.

The host resolves project-file access against the canonical project root and checks the requested path. Space source references are a separate access surface: permission to read uploaded material does not grant arbitrary disk access.

With a workspace in place, the interesting question is what actually moves between surfaces. We treat the records a task produces as different types, because collapsing them is how an investigation loses its provenance.

The browser is where this chain usually starts, so its output feeds a workspace-scoped traffic ledger. The Agent searches a bounded metadata view first — method, host, path, status, type — and retrieves bodies only on demand. That is a deliberate limit on prompt exposure rather than an optimisation: an assistant that receives every request body by default has been handed far more of a real application than the question needed.

From there, a selected request can be carried into a bounded search of the local project to find candidate handlers. Method, path and project files narrow the search. Comparing the candidate with the observed request helps the engineer determine whether it explains the application’s behaviour.

The retention mechanism is the task itself. A task is bound to a project, an objective with acceptance criteria, a set of typed context items, a selected model and provider, a sandbox and runtime profile, and the permission scope for the turn. Nothing about that binding is global state, which is what allows two investigations in the same project to stay separable.

Context items are typed rather than pasted: a file, terminal output, a browser page possibly with a specific element and comment attached, an image, pasted text, or a reusable skill. Typing them matters because a typed item can be re-opened at its source, while a pasted blob can only be read.

The other half is the activity record. Runtime events are normalised into a canonical model by adapters shared between the live path and the preview path, so the host renders one shape regardless of which transport produced the event. That normalisation is what allows the interface to reveal the exact browser page, request, file or terminal behind an action instead of describing it.

• An action that can change a real system is attributed to the actor and the turn that caused it.
• An execution that was interrupted without a provable outcome stays visible as unresolved rather than being converted into a clean retry.
• A verification result is kept with the command, the exit status and the revision it applied to.

One honest qualification: following the Agent to a surface is an interface affordance built on events the runtime emits. It is not a second execution loop, and it cannot reveal an action the runtime never recorded.

Five principles connect the architecture to the investigation. Each concerns something a reviewer should be able to recover from the record.

1. Model capability and workspace continuity solve different problems. A better model can reason over the context it receives; the workspace must retain the browser state, request record and file context that reasoning depends on.
2. Retention belongs close to the action. Captured traffic, separate request revisions and recorded command results preserve the material while it is produced, reducing the reconstruction needed when a finding is reviewed.
3. Candidates must be distinguishable from observations. A search result suggests where to inspect; a captured transaction records what happened. A reviewer needs both, with their different meanings preserved.
4. Permission behaviour has to follow the runtime, not the ambition. Interactive approvals exist on one transport and not on others, so the product states which is active and refuses an action the transport cannot approve instead of attempting it.
5. An interrupted action can have an unknown outcome. The record should preserve that uncertainty until a follow-up check establishes what happened, so a later retry can account for possible side effects.

Every structural decision above cost something, and the costs are worth stating plainly.

• The workspace coordinates routine work; it does not remove the need for an engineer. Reproduction, impact and authorisation remain human decisions throughout.
• Source retrieval follows the task project's selected Spaces; it is not access to every space. Reuse still requires checking source scope, version and freshness.
• Interactive approval is not uniform across transports. Where the runtime cannot ask, the action is refused rather than approximated.
• Following the Agent depends on events the runtime emits; an event the runtime never produced cannot be shown.

• Making the investigation record exportable in a form another team can review without the product installed.
• Extending the canonical event model to cover surfaces whose runtimes report less than the model needs.
• Measuring the cost of handoffs directly — how often an investigation has to re-derive something already observed — so that workspace changes can be compared on evidence rather than on intuition.
• Studying whether source versions, navigation and bounded retrieval reduce repeated reconstruction in practice. The second article examines this source-first continuity model.

The tools a security engineer uses are individually good and collectively disconnected. The disconnection is not a gap a more capable model closes, because what is missing is not understanding — it is the retention and movement of everything the understanding depends on.

Treating that as an architecture problem rather than an assistant problem changes what gets built: a workspace with a defined scope, typed context, retained records, explicit permissions and a reviewable trace. The model still matters, and it is no longer the whole story.