You may have heard the line “It’s 10 PM. Do you know where your children are?” While this phrase started as a 1960s PSA aimed at addressing social challenges of the day, a fitting modern version might very well be “It’s 4 AM. Do you know what your agents are doing?”
The explosion of agentic technology is forcing what feels like a real-time re-evaluation of security policy and controls. Gone are the days when an automated process did only what it was programmed for and ran only when instructed. AI agents, when left unchecked, will non-deterministically use any methods available to pursue a goal—regardless of whether the methods are what the human operator intended.
Proliferation of agents, agentic workflows, MCP servers, and powerful LLM-back tools inside the business environment means new methods of oversight and control are crucial to protect sensitive data and environments. Britive ARC™ is designed specifically to address the modern agentic identity and access challenges.
Old Problems, New Scope
Before diving into Britive ARC™, it’s helpful to set the stage for why this solution is so necessary. Perhaps the biggest challenge with AI is the speed with which the tools and agents have proliferated into seemingly every corner of modern business. Capabilities and operational boundaries are also fuzzier.
Before, machine processes were predictable. They typically did one or a small defined handful of things. They worked in a single environment. An automation would do its programmed job, then shut down until the next scheduled run. A service identity granted access to do a fixed scope of tasks in a single environment.
While such processes can be simple, traditionally there was a non-trivial amount of time and effort needed to set them up properly. Many organizations also have existing controls and tools to monitor, secure, and manage these non-human identities and workloads because of their fixed, predicable nature.
AI breaks these old assumptions. Now, an employee can connect Claude to any number of systems using his or her account credentials or feed it data form internal sources with a click of a button or a simple text prompt.
Agents can be spun up in any number of cloud or SaaS environments, or even on a local developer computer. MCP servers make it trivial to let AI agents interact with any number of resources both local and remote. And the agents are unpredictable.
Ask it to do the same thing twice and, unlike a programmed automation, the agent may decide to take a completely different approach. This flexibility is what lets agents work across systems and datatypes with a speed that was almost incomprehensible just a few years ago. It is a gap between how fast teams are building and how slowly access models have caught up. In short: what worked before for controlling human and machine access breaks down in the agentic age.
What is ARC?
ARC is Britive’s Agentic Runtime Control. It is our comprehensive approach to AI identity security, delivered through the same unified platform leading organizations use to achieve Zero Standing Privileges (ZSP) across all environments for all identity types.
It covers AI identity lifecycle management and governance, policy-driven runtime access control, and a unique combination of features you won’t find from other pure-play AI security tools or other identity security tools with AI bolt-ons.
As an agent attempts to take some action in the environment, Britive ARC™ will: Verify, Assess, Authorize, Observe, and Revoke privileges and behavior. Supporting this end-to-end runtime control is Britive’s common policy model for granular privilege control, true ZSP ephemeral permissioning at runtime, comprehensive audit logging, and a host of other platform security controls. We’ll dig into the details as we break down how this works.
It Starts with What you Have
The first step in managing something is knowing what you have and where it lives. Britive treats AI agents as first-class identities. An agent gets its own identity in Britive, not a borrowed service account and not a shared human login.
AI identities support two access types. Static identities are issued a workload token with an administrator-defined validity period. Federated identities authenticate through a workload identity provider, with token duration governed by the provider itself. Federation for AI identities supports OIDC, AWS STS, and SPIFFE SVIDs. A validation window defines how long after issuance Britive will accept the token for verification.
Every AI identity carries a job function, a business use description, and an owner. That last one is a key part of an effective AI governance program. An agent without a named human owner is an agent nobody is accountable for. Out of the box reports make it easy to identity ownerless AI identities or those where the owner account is inactive.
Britive can also facilitate onboarding by discovering agents running in AWS Bedrock and AgentCore, Azure Foundry, and Google Vertex. Agents are scanned in from your cloud environments along with associated roles and privileges. Once an agent is onboarded in Britive, it can be assigned granular privileges to resources through policies and access profiles.
Ready, Set, Action!
AI agents are all about the actions they take. Their great promise is their ability to grab information from disparate sources and synthesize it into something useful with minimal user effort. In the past, APIs were the standard way to interface data and resources with software programs.
In the agentic age, Model Context Protocol (MCP) is the new game in town. MCP standardizes how a large language model (which power most agents) reaches systems and data. An MCP server exposes tools, an MCP client connects an agent to those servers, and the agent calls the tools it needs. Standardization made agentic workflows composable in a way they simply were not before, which is exactly why adoption moved so quickly.
As an example, MCP servers let a developer type a brief command into their coding agent of choice to kick off a chain of events: the agent connects to a repo (GitHub MCP server) to push a new code branch, updates a Jira ticket (Atlassian MCP server), and drops a chat message to a team member for review (Slack MCP server). Creating this workflow required zero coding or any setup beyond basic authentication into each server.
But with this low barrier to connection agents to systems with sensitive corporate information, how do you provide control without adding in productivity-crushing security processes and tooling? That’s where Britive’s MCP Gateway comes in.
Not Just Another MCP Gateway
See Britive's MCP Gateway in action:
You can think of an MCP server as a new door into an enterprise system, frequently opened outside of security's view. An MCP gateway addresses that by centralizing the connections. A good one gives you four things:
- A registry of downstream servers, so someone owns the list of what agents can reach.
- Per-identity tool filtering, so an agent cannot see a tool it is not entitled to.
- Central token custody, so clients never hold the secret themselves.
- A log of tool invocations, so there is something to review afterward.
If you are evaluating gateways right now, expect all four. Any credible product has them, ours included. The gateway ideally serves as the single ingress/egress point for all MCP traffic across your environment. Backend MCP servers can be network-restricted and client-restricted so that only the gateway holds a valid connection path and valid connection credentials.
The ARC Flow
Now let’s go back to how ARC maps controls to the phases of agent action. Britive ARC™ is a conceptual model, not a technical architecture. The steps are meant to show the security journey of an AI agent’s access.
Verify: Do we recognize this agent?
When an agent needs to access an MCP server, it’s only point of access is through the gateway. It presents the gateway with proof of identity, usually in the form of a token (OIDC, SPIFFE, etc. for agentic identities or OAuth for human-controlled agents like Claude Desktop). Britive verifies this agent is recognized in the platform registry and properly authenticated, using an allowed delegated identity where applicable. If the agent is known, it keeps going; otherwise, it’s denied at the front door.
Assess: What is the agent trying to do?
The authenticated agent is asking to do something. Britive evaluates the intent of the agent’s requested action and captures the prompt: what is it stating it wants to do, what is it trying to access, and what’s the context driving it? These details are all logged and the request moves on to the next stage.
Authorize: Should this action be allowed right now?
The agent is trying to use a particular tool on a specific MCP server. Here again the gateway checks with the Britive platform to assess whether this agent identity is allowed to call the specified server and tool. Britive makes the runtime decision to allow, deny, or provision the access required for the action. Privilege is created only when authorized and only to the extent required.
Side Notes on Authorization:
Admins configure in Britive all allowed MCP servers available through the gateway. Policies determine which identities are allowed to reach servers and which tools may be used. When a call is allowed and requires elevated access, the same checkout machinery that governs human and workload access creates the privilege for that task, either by elevating permissions inside the target system's own access model with no credential issued, or by minting an ephemeral credential the agent never sees—and removes it when the task ends. This is a distinguishing feature of Britive. Other gateways hand over a credential that already existed.
The MCP spec recently moved towards an OAuth-only model for authenticating to MCP servers. This is a smart security decision that actually presents a complication for MCP-fronted resources like databases that understand usernames and passwords, not tokens.
For a server fronting a database, the gateway checks out temporary access on the Britive platform, packages the resulting credentials as HTTP headers on the forwarded tool call, and the downstream MCP server unpacks them at runtime to connect. The MCP server itself stores no credentials at all; it needs only network connectivity to the database. The same pattern can create an ephemeral account inside the database for the task and remove it afterward. This is how a standard MCP server becomes a stateless, credential-less component without modification to its tools—and without exposing a static credential to an agent.
Observe: Should it continue to be allowed?
Britive continuously observes the agent's behavior, actions, and context while the work runs, and re-evaluates the authorization as conditions change. Live signals including Shared Signals Framework (SSF) CAEP and RISC events from ecosystem security tools can trigger deeper enforcement, require human intervention, or revoke access mid-task when it is no longer authorized.
Britive goes even further, checking agent actions on the inbound side and data on the outbound side. Where the connection to a database or server is routed through Britive, enforcement continues at the command level. Britive understands native protocols including SSH, RDP, MySQL, Postgres, Cassandra, Kubernetes, and an HTTP-proxy mode for API and kubectl traffic and can monitor the connection path between an agent and the resource.
For instance, agents issuing “CREATE” or “DELETE” commands to a database have these commands blocked before they ever hit the server. Command policy is associated with the checkout that created the temporary credentials. The block command set is a property of the grant, not a standalone “firewall” rule that trigger regardless of the identity, tool, or server involved in the request.
As data returns from the downstream server, the gateway inspects every return payload by default. The gateway is looking for information in the return payload that may be dangerous such as a prompt-injection hidden in a wiki page. It also checks for patterns including URLs on a block list (client-provided lists plus built-in ones); obfuscation (zero-width characters, Unicode tag characters, Base64-encoded payloads); and secrets present in responses (AWS keys, GitHub tokens, SSH keys, Slack tokens, and similar).
There are two modes to deal with unwanted data in the response. When run in audit mode, the response is delivered and an event with the findings is written to the audit log (webhooks are easily configured to push these events to the SIEM or SOAR). The other option is enforcement mode where the response is blocked and the event is logged.
Britive can also record the full session for agents. Every routed session detail is recorded: SSH and RDP keystroke by keystroke, database sessions query by query, HTTP sessions as a downloadable HAR file. Every command across every recorded session is searchable because the gateway logs every action in the same session with a unique identifier. Sessions can be viewed live. Recordings can be viewed in the console or downloaded as video or CSV. Oversight controls on live sessions let users lock it mid-command or disconnect the agent.
Revoke: When should access disappear?
Britive removes privilege the moment it is no longer authorized or required—whether the task is complete or conditions change while the work is running. A blocked command or forbidden data as described above are good candidates for triggering an immediate revocation.
Other security tools in the environment such as the EPM on end user machines or network monitoring/NDR tools generating SSF events (CAEP / RISC) are other good signal sources for removing an agent’s access immediately. Behavioral or environmental signals communicated to the Britive platform ensure a misbehaving or potentially compromised agent is neutralized immediately. And because Britive offers true ZSP for all identity and resource types, no privilege remains. Revoked means completely gone, not merely hidden from this identity.
Proof is continuous
Underlying the entire arc of Britive’s agent runtime control is a solid foundation of proof. Britive maintains continuous evidence of identity, intent, authorization decisions, privilege, actions, and outcomes as the transaction happens, supporting audit, investigation, and compliance without reconstructing the transaction afterward.
The gateway injects three parameters into every tool it exposes (a session identifier, the user's prompt, and the model's stated intent for invoking the tool), which the client supplies with the call. The gateway logs them alongside the tool name, arguments, identities, decision, and outcome, and does not forward them to the backend server, which never sees them. The session identifier is shared by every call in a chat or agent run, so an entire multi-step run is one query in the audit log rather than a reconstruction across systems. The platform's checkout record (profile, approvals, TTL) and the Bridge session record share a transaction identifier, so the authorization decision, the privilege issued, and the statement that actually reached the resource can be joined.
Gateway tool calls, checkouts, elevations, and Bridge session activity land in the platform audit log alongside human and non-human identity events as the same kind of record, comparable side by side, with export to SIEM and SOAR.
The Wrap-up
It’s hard to capture the breadth and depth of Britive ARC™ without making this already lengthy piece much longer. We hit the main highlights but there’s even more capabilities and details that make up ARC.
The important takeaway is that ARC is for organizations looking for help addressing the AI identity, access, and governance challenges they face today—and will face tomorrow. ARC is not a separate product or standalone solution; it is a comprehensive set of capabilities extending from Britive’s unified identity security solution.
ARC inherits and builds on all the advantages of Britive’s one common policy model, one comprehensive audit log, and one control point for ephemeral access and ZSP enforcement for human, machine, and agentic identities into any resource type. The agentic future is here, it’s messy, and it’s evolving at an unprecedented speed.
Britive ARC™ is your way to bring security and control to the madness, without sacrificing the flexibility and speed that makes agentic technology so powerful.
