Input and Output Guardrails

CORRA combines authenticated access controls, restricted agent capabilities, persistent operating instructions, and existing Corridor authorization to constrain both the information available to the model and the actions it can perform.

Corridor MCP tool safety

Authentication and workspace isolation

Every MCP request is associated with a verified Corridor user and workspace.

For CORRA, the user and workspace context comes from the authenticated Corridor session established through the institution’s configured SSO/authentication mechanism. For external MCP clients, the identity is established through the MCP OAuth authorization flow.

Identity is taken from the verified access token rather than caller-supplied identity headers. This prevents an MCP client from selecting a different user or workspace simply by modifying request metadata.

Existing Corridor authorization

MCP does not introduce a parallel data-access model.

Tool calls execute through Corridor services using an authenticated AppUser context. Existing object-level authorization is therefore applied to data requested through CORRA in the same way it is applied elsewhere in the Corridor platform.

This ensures that the AI interface does not bypass the application’s established permission model.

Explicit tool capability boundaries

CORRA can use only the capabilities explicitly exposed through its configured tools. Corridor MCP tools are classified as either read or write: read tools search, retrieve, inspect, compare, and query Corridor data, while write tools can make changes. Each invocation remains subject to Corridor’s existing authorization and workflow controls.

The classification is published with each tool, so a connected agent can tell the two apart before calling anything. Clients use this to decide how much confirmation an action needs, for example prompting the user before running a write tool while allowing read tools to run freely.

Generated artifacts remain subject to the platform’s normal review, registration, testing, and approval workflows.

This separation prevents an AI-generated recommendation from independently becoming an approved production change.

CORRA AI safety

Prompt-injection protection

CORRA’s persistent operating instructions establish a trust boundary between agent instructions and retrieved content.

User messages, attachments, documentation, logs, report contents, and MCP responses are treated as data rather than as privileged agent instructions. Instructions embedded inside retrieved content cannot redefine CORRA’s role, authorize additional capabilities, or override established governance controls.

Restricted runtime capabilities

CORRA operates with a deliberately constrained runtime.

Capabilities such as unrestricted shell execution, arbitrary file editing, generic web fetching, and other open-ended system tools are denied to the primary CORRA agent.

Corridor application data is retrieved through defined MCP tools, providing a narrower and auditable interface to platform resources.

Unexpected runtime permission requests are rejected.

Grounded responses

CORRA is designed to rely on Corridor tools for data retrieval, analytical operations, and deterministic business logic wherever possible.

The agent primarily interprets user intent, selects and orchestrates tools, and explains their results. Authoritative values, calculations, and platform-specific logic are produced by governed tools rather than inferred by the LLM.

This keeps deterministic computation within Corridor while using the model for natural-language interaction and synthesis.

Output safety and governance

CORRA operates under persistent safety and governance instructions in addition to its technical tool restrictions.

The agent is constrained from:

• bypassing platform governance or authorization;
• automatically approving or deploying generated changes;
• representing generated analysis as an unsupported compliance or legal guarantee;
• following instructions embedded in untrusted retrieved content;
• performing actions outside its permitted tool set; and
• presenting unsupported platform values as established facts.

Together, these controls provide defense in depth across identity, authorization, retrieval, agent behavior, runtime capabilities, and generated output.

PII and sensitive-data handling

CORRA’s first data-protection boundary is Corridor’s existing authorization model: only data available to the authenticated user and workspace can be retrieved through MCP.

Tool interfaces are scoped to the information required for the requested operation, reducing unnecessary data exposure between platform services and the agent.

Sensitive credentials and authorization values are redacted from diagnostic logging. Configuration APIs also return masked representations of stored secrets rather than exposing credential values.

The same data-governance principles apply to downstream AI and observability integrations. LLM-provider and observability configurations can therefore be aligned with the customer’s approved data-handling, retention, residency, and access policies.

Guardrail summary

Control	Enforcement
Authenticated user and workspace identity	Established from the authenticated Corridor SSO/session for CORRA or OAuth for external MCP clients
Existing Corridor object permissions	Applied through Corridor services
Explicit read/write tool capability boundary	Applied through the configured MCP tool set and underlying Corridor authorization/workflow controls
Prompt-injection protection	Persistent agent trust-boundary instructions
Unrestricted shell, arbitrary file editing, and generic web tools	Restricted for CORRA
Automatic governance bypass	Prohibited
Automatic approval/deployment of generated code	Prohibited
Secret and credential exposure in diagnostics	Redacted
Grounded analytical behavior	Applied through agent and tool workflows
Safety and governance boundaries	Applied through persistent agent instructions and tool restrictions