Tegrix control plane
Inventory, External Graph context, Policy & Controls, approvals, decisions, and evidence are operated from Tegrix.
Architecture
Add control without replacing the agent stack.
Tegrix connects to existing agent platforms and enterprise systems, builds the agent inventory and External Graph, applies Policy & Controls at runtime, returns a decision, and keeps the evidence.
Start with read-only visibility across platforms.
Use runtime controls only where agent actions need a decision.
Keep official systems authoritative while Tegrix retains the control evidence.
Architecture fit
Existing platforms stay. Tegrix controls the action boundary.
1Connectors
2Agent inventory
3External Graph
4Policy & Controls
5Runtime decision
6Execution or prevention
7Evidence
Where Tegrix runs
Tegrix sits beside the stack, then controls selected action paths.
Existing platforms
Microsoft, AWS, Google, SaaS tools, identity systems, logs, and business systems continue to run in place.
Runtime control points
Controls are added only where an agent action needs a decision before execution continues.
Deployment boundary
Hosted SaaS is the default evaluation path. Stricter customer-cloud or hybrid boundaries can be evaluated where required.
How Tegrix connects
Use the lightest connection that proves the control decision.
Read-only APIs
Start by bringing in inventory, identity, ownership, configuration, tool, and event signals.
Provider adapters
Normalize platform-specific agent records into a common operating view.
SDK integration
Use SDK calls when customer-built agents need a Tegrix decision before a governed action.
Wrappers or governed tools
Place controls around high-impact tools without replacing the agent platform.
Optional gateway or sidecar
Use only when the workflow needs an inline traffic or tool-invocation boundary.
What data Tegrix requires
Enough context to decide. Enough evidence to explain.
Inventory metadata
Agent name, provider, environment, owner, status, source, and last-seen signals.
Ownership metadata
Team, business owner, technical owner, identity, service principal, and approval path.
Relationships
Tools, systems, data classes, workflows, policies, controls, and runtime events.
Decision envelope
The action requested, relevant facts, matched controls, decision, and execution state.
Evidence record
The retained record needed to explain what was attempted, decided, invoked, prevented, or approved.
Runtime characteristics
Runtime choices should be explicit before enforcement.
Decision path
A governed action is sent to Tegrix, evaluated against context and controls, then returned as allow, deny, hold, redact, or approval required.
Provider invocation
The provider still executes the action when allowed. Tegrix decides whether the action should continue.
Failure behavior
Fail-open or fail-closed behavior should be chosen per governed path based on business impact and risk.
Availability
Runtime paths should be designed with the customer's resilience requirements before enforcement is enabled.
Evidence persistence
Decision records are retained for governed actions so review does not depend on screenshots across tools.
Data boundary
Tegrix should receive the fields required for a decision and evidence record, not a full copy of every source system.
Canonical flow
One technical flow is enough.
Connectors build visibility. External Graph adds enterprise context. Policy & Controls return a runtime decision. The provider executes only when the decision allows it, and Tegrix keeps the evidence.
Connectors
Agent inventory
External Graph
Policy & Controls
Runtime decision
Execution or prevention
Evidence
Architecture FAQ
Questions your platform and security teams will ask before enforcement.
Adapter placement
Where does control run?
Tegrix can start read-only, then add SDKs, adapters, wrappers, governed tools, or gateways where a workflow needs a runtime decision.
Latency
What delay is added?
Decision timing should be measured on the governed path during evaluation. Do not enforce a path until the business owner accepts the decision window.
Availability
What if Tegrix is unavailable?
Fail-open or fail-closed behavior should be chosen per governed action before enforcement goes live, based on business impact and risk.
Data boundary
What crosses the boundary?
Tegrix should receive the fields needed for inventory, context, policy decisioning, approvals, and evidence, not a full copy of every source system.
Policy deployment
How does policy go live?
Controls are packaged, assigned, tested, and published to the governed path selected by the customer.
Evidence integrity
Can the record be trusted?
The evidence record should retain the action, evaluated facts, matched controls, decision, provider invocation state, approval, and final outcome.
Integration scope
Where does it work?
Existing Microsoft, AWS, Google, SaaS, and custom agent platforms remain in place. Tegrix connects where visibility, context, evidence, or runtime control is needed.
Authority
Whose authority is checked?
Tegrix can evaluate owner, requester, runtime identity, service principal, policy assignment, approval path, and business context before a decision is returned.
Graph freshness
How does context stay current?
Connectors and runtime events refresh inventory, ownership, tools, policies, data relationships, and evidence as the environment changes.
Not gateway-only
Why not just a gateway?
Gateways operate traffic and routing. Tegrix is focused on the enterprise action: context, policy, decision, approval, provider state, and evidence.
Review the connection model, deployment boundary, runtime behavior, and evidence record before expanding enforcement.
Open white paper