Gateway model
Interception is enforcement. One point carries every agent.
Our approach
If you can’t understand an agent from the outside, why control it from there?
Geordie instruments the harness the agent runs inside, not the wire it talks over. Understanding comes from the agent’s own configuration, context and behavior – and so does the control.
Trusted by forward thinking teams
What an agent is
An agent is a system with an identity, tools, permissions, memory, a cost, an owner and a history of what it actually did.
Every one of those lives inside the agent. Geordie is built to sit there, which is why our understanding is not a reconstruction, and our controls are not a chokepoint.
-
A gateway asks
Should this request be allowed through?
-
A sensor asks
What just happened on this device?
-
Geordie asks
What is this agent trying to do, with what, for whom, at what cost – and should it be doing it?
Why Geordie
Agent control along the lifecycle, not at a gateway
Agents cross cloud, code, endpoint and browser. A product built around one surface or one traffic type sees the snapshot that crosses its boundary.
Geordie works from inside the agent’s harness. Lifecycle-hook instrumentation reads configuration, context and memory, so coverage extends everywhere, not just MCP.
Where enforcement happens
Agent-native model
Interception and enforcement are separate. Controls sit in the agent’s own configuration.
“Purpose-built” is only as effective as your position
-
Outside · repurposed
Platform bundles
Agent controls added to a much larger existing suite. Enormous distribution, low procurement friction, and agent governance as a line item rather than the core bet.
Depth lags until the vendor commits dedicated engineering.
-
Outside · purpose-built
Gateways and traffic boundaries
Built for agents, but enforcing at a chokepoint. For most, the interception mechanism is the enforcement mechanism - one component doing both jobs.
Coverage stops at the tool types that pass through it.
-
Inside-ish · purpose-built
Endpoint and browser sensors
A sensor or extension on the device. Genuinely closer to the action, and useful for what runs where a person is sitting.
A ceiling that does not reach cloud-hosted, code-level or multi-agent surfaces.
-
Inside · purpose-built
Harness-native lifecycle hooks
Instrumentation attached to the agent’s own execution path, across cloud, code and endpoint, with enforcement separated from interception.
Where Geordie sits. Almost nobody else is here.
What proximity buys you
We read the agent. We don’t watch it.
Watching from outside
Inference
- You see a request and work backwards to a motive
- You see the tool types that pass your boundary, and none of the others
- You classify intent at the wire, then apply one policy to every agent behind it
- Your visibility is a sample of a session, taken at a chokepoint
Reading from inside
Evidence
- You read the objective the agent was given, and the plan it formed
- You see every tool the agent can reach, including the ones that never produce traffic
- You apply a control through the agent’s own configuration, specific to that agent and department
- Your record is the whole decision-making lifecycle, as it happens
This is not a claim about effort. It is a claim about position. A tool that sits outside the agent cannot read the agent’s memory no matter how good its detection is, and a tool that reads the agent’s memory does not need to guess.
The agent lifecycle
Every agent runs this loop, whatever framework it sits in. Where you attach to it determines whether you are governing the work or auditing the exhaust.
-
01
User input
-
02
Memory and context
-
03
Reasoning
-
04
Tool calls
-
05
Runtime decisions
-
06
Response
Gateway
Single chokepoint
Geordie
Geordie attaches throughout
- Which agent, which harness, who asked, and what for.
- Configuration, loaded context, skills present, memory carried over.
- The plan, while guidance is still free to give.
- Every tool type — skills, extensions, plugins, packages, connectors, direct API.
- The decision, in the context of the whole session.
- The outcome, the owner, the tokens, immutably recorded.
-
01
User input
Which agent, which harness, who asked, and what for.
-
02
Memory and context
Configuration, loaded context, skills present, memory carried over.
-
03
Reasoning
The plan, while guidance is still free to give.
-
04
Tool calls
Every tool type — skills, extensions, plugins, packages, connectors, direct API.
Single chokepoint the only step a gateway attaches to
-
05
Runtime decisions
The decision, in the context of the whole session.
-
06
Response
The outcome, the owner, the tokens, immutably recorded.
- Geordie attaches throughout
Illustrative example
This is what “we know the agent” actually means
agent
claims-triage
Critical risk
The same platform, deployed in marketing, scores low on all five risk dimensions. Department and data classification are inputs, not tags applied afterwards.
- identity
- A service principal with delegated access to two policy systems and one payments API
- tools
- 2 MCP servers · 3 skills · 1 IDE extension · 1 hard-coded API integration
- data reach
- Policyholder records, medical notes, payment instructions
- reversibility
- Can issue an irreversible payment instruction — weighted above any read
- behavior
- Baseline established over 6 weeks · 3 deviations flagged · 0 unexplained
- controls
- Payment instruction requires a policy match — binding hook, not a suggestion
- cost
- £96,400 last month · 84% on claims intake · 11% on retried tool calls
Remediation, powered by Beam
Beam · the control spectrum
Governance is not a binary. Neither are our controls.
Allow or block is the only vocabulary available to something sitting outside the agent. From inside, a control can be binding, or it can be guidance — and both are deterministic.
-
Binding
The agent has no option
Lifecycle hooks are binding. A prohibited action or tool call does not execute. No negotiation, no model judgement.
-
Conditional
Allowed, if the context permits it
An agent authorised to process financial data can. One that is not, is steered away. Same platform, same tool, different answer.
-
Redirected
A safer route offered before the risky one
Added context and a recommended pathway, injected into the reasoning step. The work continues; it just continues differently.
-
Nudge
Guidance that makes the agent better
Behavioral nudges shape decisions through deterministic rules rather than mechanical constraint. Customers report governed agents becoming more reliable over time.
No LLM judges another LLM here
We use AI for analysis, behavioral understanding and anomaly detection, where it is genuinely the best tool. Policy creation and enforcement are deterministic, because an enterprise governing autonomous systems at scale cannot afford layered non-determinism. Every control behaves the same way every time.
Why we scale where others don’t
Seeing and stopping should not be the same component
With a lot of tools, the thing that intercepts agent communications is the same thing that applies policy.
That single design produces critical limitations.
One component, two jobs
- Coverage is capped by what routes through it
- Latency is added to every governed action
- Scaling limits arrive at enterprise agent volumes
- When it cannot decide, it fails open or fails closed — and it is a single point of failure either way
Two layers, separated
- Coverage grows by adding interception mechanisms, without touching enforcement
- No external chokepoint in the execution path, so no added latency
- A US financial data company runs hundreds of thousands of agents daily under inline controls, without operational disruption
- No fail-open or fail-closed binary, because there is nothing to fail through
The controls that keep agents safe are the controls that make them better
A team that can baseline behavior, understand context and shape decisions deterministically is not just reducing risk. It is making agents more reliable, more trusted by the organization, and eventually capable of more responsibility.
That is the argument for governance that the risk framing misses entirely. Customers using Beam’s behavioral nudges report governed agents becoming more reliable over time — the same mechanism, producing a second outcome nobody bought it for.
Every enterprise will define value differently. Different agents, models and systems; different appetites for risk; different views on where agents should work. We provide the understanding and the mechanisms. You decide what good looks like.
The loop
- 01 Observe what the agent actually does From inside the execution path, continuously.
- 02 Compare it to what it was meant to do Declared configuration merged with observed behavior.
- 03 Shape the next decision Binding where it must be, guiding where that works better.
- 04 Prove what happened Immutable evidence, mapped to your frameworks as they evolve.
- 05 Give the agent more to do Which is the whole point, and the only outcome the business actually asked for.
Cost intelligence
The behavioral record and the financial record are the same
This is not a second product bolted on. The instrumentation that captures what an agent did also captures token counts, model identifiers and activity metadata — because it is watching the work, not the wire.
One event
An agent acted: which one, what it did, what it touched, who owned it, what it consumed.
Asked as a security question
Was that appropriate?
- Behavior against baseline, with the context that makes it legible
- Immutable audit evidence, even where the platform allows session replays
- Risk scored deep — to the tool, user, credential and permission
Asked as a financial question
Was that worth it?
- Spend attributed to the agent, the action and the owner
- Waste made visible: retry loops, orphaned sessions, duplicated agents
- Cost of a piece of work followed across every child session it fanned into
Most tools that surface agent cost are disconnected from the behavioral context that explains why the cost exists. An early adopter of our cost intelligence gained attribution of agent spend back to specific agents, actions and owners for the first time — and the security team that can present both pictures to the board arrives in a stronger position than one that can present either.
If you are comparing options
Five questions to put to anyone in this category. Us included.
Funding rounds and analyst placements are trailing indicators. These five answers tell you where a product actually sits, and what it will be able to do in eighteen months.
-
01
Where does enforcement happen, and is it the same component that does the watching?
If interception and enforcement are one thing, coverage and scale are permanently tied together. Ask what happens when it cannot decide.
-
02
Can it see skills?
The single fastest diagnostic in this category. Skills live in the agent’s configuration and produce no outbound traffic, so anything that watches from outside cannot see them. Ask for a demo, not a roadmap.
-
03
Are the policies deterministic?
If an LLM generates or judges the policy, enforcement can change without anyone changing it. Ask whether the same input produces the same decision every time, and whether they will put that in writing.
-
04
Can the same product tell you what it cost?
Not a cost dashboard alongside it — cost attributed to the agent, the action and the owner, from the same record as the security evidence. If those come from two systems, they will disagree.
-
05
How many surfaces, and how many enterprise references?
An agent’s configuration, tools and data access commonly sit on three different surfaces. Ask which ones are covered today, in production, at what scale — and ask to speak to someone running it.
What our approach produced, in real deployments
-
327%
more agents than the CISO and security team expected, with no reconfiguration required to onboard.
-
100k+
agents a day under inline control at a US financial data company, with no operational downtime.
-
$12–13M
in risk averted, once the agents and tool connections nobody had counted were on one record.
“My leadership team approved these tools because I could show them what the agents were doing. Not what the model was doing. Not what the network was logging. What the agent was actually doing, step by step, on their behalf.”
“Geordie’s approach gave us visibility close to where agent activity happens, without forcing us into a more complex gateway-based model. It gave us the balance of visibility, governance and architectural simplicity.”
See what sitting inside the agent actually shows you
We will plug in one platform and walk you through the findings. Most teams learn something about their own estate in the first ten minutes.
- 30 minutes, run by an engineer, not a demo script
- Read-only access, revoked whenever you like
- No agent rebuilds, no reconfiguration, nothing rerouted
- A findings summary you can forward internally
Demo request form
Thank you!
Your request has been received.