Fugitive Control roadmap

A control path for AI agents that take action.

Fugitive Control is in founding development. The target architecture is a vendor-neutral policy and evidence layer for agents that reach enterprise data, credentials, APIs, applications, and operational systems.

Discuss a design-partner pilot Start with an exposure review

How to read this page

Architecture direction, not a feature availability promise.

A design-partner engagement can validate a narrow subset against one or two workflows. Only a signed agreement defines capabilities, deployment, data handling, testing, support, acceptance criteria, and timing.

TARGET

Identity, authority, policy, and evidence

The roadmap is organized around action-level controls rather than broad claims about model safety.

PILOT

One consequential workflow

Initial validation should use a bounded workflow, test identities and data where practical, explicit stop conditions, and accountable owners.

BOUNDARY

No certification or guaranteed outcome

The roadmap does not establish compliance, prevent every incident, or replace the client’s legal, audit, identity, cloud, API, or security responsibilities.

Target control architecture

Stand between machine intent and business impact.

The planned architecture places a policy decision point in the action path and uses identity, data, security, workflow, and business-system context.

Agent sources

Application agents

Employee copilots

Autonomous workflows

Third-party agents

Fugitive Control

Intended role: resolve identity, evaluate delegated authority, apply action policy, route approvals, and preserve a connected record for in-scope tool calls.

Agent and action graphDISCOVER

Delegated authority engineAUTHORITY

Tool-call policy gatewayGUARD

Approval and containmentCONTROL

Evidence and assurance ledgerTRACE

Enterprise systems

Customer and data systems

Code and deployment tools

Communications

Financial and privileged APIs

01 / DISCOVER

Map the AI Action Graph.

The planned discovery layer starts with an agreed map of agents, owners, models, tools, MCP servers, identities, credentials, data sources, and high-impact workflows.

The graph is designed to answer the questions conventional inventories miss: which agent can affect which business system, under whose authority, through which path?

Agent and owner inventoryIdentify production, pilot, embedded, employee-operated, and third-party agents with accountable owners.
Tool and MCP topologyMap servers, tools, actions, transports, credentials, trust boundaries, and downstream dependencies.
Sensitive data pathsConnect agent workflows to regulated, confidential, customer, financial, and proprietary data.
High-impact action analysisPrioritize actions that move money, change code, alter records, contact external parties, or create irreversible effects.

02 / AUTHORITY

Define a bounded mandate.

The authority model is intended to avoid giving an agent the full power of a human account or long-lived service credential. It should state what the agent may do, for whom, where, when, and up to what value.

Authority can be constrained by action, data class, tenant, customer, record, destination, geography, amount, time window, workflow state, and responsible human.

Resolvable agent identityBind a stable agent identity to the initiating user, application, workflow, model, and deployment.
Least-privilege action scopesAuthorize exact operations rather than broad API, application, or database access.
Short-lived delegated credentialsIssue narrowly scoped credentials that expire with the task instead of persisting in model context or configuration.
Separation of dutiesPrevent one agent or user from initiating, approving, and completing a sensitive transaction alone.

03 / GUARD

Enforce policy at the tool call.

Content filtering cannot replace authorization. Guard is designed to evaluate the requested action, current context, target system, data, recipient, transaction value, and declared mandate before execution.

The target decision set includes allow, deny, redact, transform, rate-limit, constrain, and route for accountable human approval.

# Customer support refund policy
policy "refund-control" {
  agent       = "support-agent"
  tool        = "payments.issue_refund"

  allow when {
    customer.tenant == request.tenant
    refund.amount <= 500 USD
    case.status == "approved"
  }

  require_approval when {
    refund.amount > 500 USD
    approver.role == "finance-manager"
  }

  deny when {
    destination != original_payment_method
    customer.data_class == "restricted"
  }

  evidence = "full-action-record"
}

04 / TRACE

Preserve a connected action record.

An investigation should not require reconstructing intent from a chat log, identity from an API gateway, data access from a database, and approval from a ticket.

Trace is intended to create an append-only record connecting the agent, delegated authority, model reference, request, tools, data, policy evaluation, approval, execution result, and related context.

Decision evidenceRecord the rules, context, signals, and exceptions used to allow, deny, modify, or escalate an action.
Data and tool lineageConnect retrieved information, generated instructions, intermediate tools, and final side effects.
Review-oriented searchFind records by agent, user, customer, tenant, tool, policy, data class, approval, destination, or outcome.
Evidence exportsOrganize repeatable records for customer reviews, governance, incident response, audit support, and executive oversight.

05 / ASSURANCE

Test the mandate repeatedly.

A policy is only useful when it withstands prompt injection, poisoned context, tool metadata changes, privilege escalation, cross-tenant attempts, approval bypass, and chained actions.

The assurance roadmap connects authorized adversarial tests to control changes and organizes evidence for internal policy, customer review, and selected AI risk frameworks.

Authorized agent and MCP testingExercise agreed cases such as goal hijacking, tool poisoning, token abuse, command injection, sensitive-data leakage, and unsafe chaining.
Control regression testsRe-run security cases when models, prompts, tools, permissions, servers, or workflows change.
Framework mappingOrganize evidence for NIST AI RMF, ISO/IEC 42001, OWASP agentic guidance, internal policy, and customer questionnaires.
Executive control reportingShow inventory coverage, high-risk actions, approval coverage, blocked actions, exceptions, response readiness, and unresolved exposure.

06 / CONTAIN

Contain the smallest affected path.

The target containment model avoids disabling unrelated AI features where a narrower response is available. It should support revocation by agent, credential, tool, tenant, workflow, destination, or action class.

Each emergency control should be tested before use, preserve relevant evidence, and support a documented recovery path.

Selective revocationDisable a specific agent, identity binding, credential, MCP server, tool, action, tenant, or destination.
Policy safe modeMove affected workflows to read-only, human-approved, or deny-by-default operation.
Evidence preservationFreeze relevant logs, decisions, tool responses, model context references, and approval records.
Controlled restorationRequire remediation, validation, approval, and monitored re-entry before restoring autonomous action.

Design principles

Independent, enforceable, and evidence-first.

These are design goals for a control layer that should remain useful as models, frameworks, clouds, identity systems, and enterprise tools change.

Vendor-neutral

Apply consistent policy across model providers, agent frameworks, MCP servers, clouds, and enterprise applications.

Default-deny for impact

Unknown or high-impact action paths should fail closed or move to accountable human review.

Identity before content

Resolve who and what is acting before attempting to interpret whether the request sounds safe.

Minimum necessary context

Expose only the records, fields, tools, credentials, and time window required for the current task.

Humans at consequential edges

Reserve accountable approval for sensitive, irreversible, regulated, novel, or high-value actions.

Evidence by construction

Create the action record during policy evaluation and execution rather than reconstructing it only after an incident or review request.

Design-partner starting point

Validate one consequential workflow.

A potential pilot would focus on a narrow action path: an agent and tool-call policy gateway, accountable approval, selective revocation, and a connected action record. Feasibility and scope must be confirmed before commitment.

Select a workflow with a named owner and measurable business effect
Agree the environment, integrations, data handling, testing limits, and stop conditions
Define acceptance criteria and evidence in a signed statement of work

Discuss a design-partner pilot