IntSen

Trust center

Control access.
Investigate outcomes.
Establish accountability.

Everything a CISO, enterprise architect or procurement team needs to evaluate IntSen: how it is built, what it records, who can do what—and what it does not control.

Limitations

What IntSen controls—and what it doesn't

IntSen governs model traffic routed through its gateway. It does not host your agents, execute your tools or see inside your runtime.

Visible through the gateway

  • Who may call which models, for which use case and data class
  • Guardrail checks on inputs, tool results and replies of governed calls
  • Budgets and per-turn limits, enforced before the provider is called
  • Records of every governed request, verdict and turn

Not visible from model traffic alone

  • Calls made outside the gateway with a direct provider key
  • Tool executions and actions inside your agent's environment
  • Data your agent retrieves but never sends to a model
  • What your application finally shows the user, if it changes the model's answer

Security questionnaire

Questions procurement teams ask

Does IntSen hold SOC 2, ISO 27001 or similar certifications?

Not today. IntSen is in its first release. We will share our architecture, controls and test results in a security review, and keep this page updated as that changes.

How is access to models authenticated?

Every application and agent signs in with its own OAuth client (client-credentials flow). The gateway validates the token and the client before any other check. Calls without a valid token are refused.

How is authorization decided?

A policy decision point checks, in order, that the call names a registration, that it exists and is ready, that the client is bound to it, and that the provider, endpoint and model are approved for it and cleared for its data class. Each denial returns a specific code and is logged.

Who holds the model-provider keys?

The gateway. Keys are injected into each call after authorization, so applications and agents never hold them. IntSen's own headers are removed before the call reaches the provider.

What happens if a guardrail or policy component fails?

Access decisions fail closed. Guardrail checks fail open by default: the call continues and the failure is recorded. A stricter fail-closed setting for guardrails is designed; confirm availability for your pilot.

What data does IntSen store?

Request records (identity, use case, agent, model, tokens, cost, timings, status), guardrail verdicts (category and score, never content), turn records and evaluation results. Request and response bodies only when body capture is on for the use case, for its retention period, with optional personal-data redaction.

What are the deployment requirements for our agents?

Your agents need HTTPS access to the IntSen gateway, an OAuth client-credentials token from the identity provider registered for them, and a model client that accepts a base URL and headers. The IntSen deployment model itself is agreed during the pilot.

Where is data hosted?

The deployment model and hosting location are agreed with each customer during the pilot. We do not publish region or residency commitments yet.

Can agents bypass the gateway?

Code that holds a provider key can call the provider directly, and those calls are not governed. Centralizing provider keys in the gateway is what makes bypass visible and avoidable; removing direct keys is part of rollout.

Does IntSen observe what our agents do with tools?

Only through model traffic: the tool calls the model requests and the results your agent sends back. Tool executions themselves, and actions whose results are not returned to the model, are not observed.

Bring your security team.

We'll walk your security architects through the trust boundaries, data flows and controls, and answer your questionnaire.