gatewaystack

user-scoped authentication and governance for llm and agentic apps (apps sdk + mcp)

until now, most ai systems have been built around model access, not user identity.

access typically happens through a single api key — often shared across a team, department, or entire organization.

that makes it impossible to answer basic questions:

at a glance

gatewaystack is a user-scoped trust and governance gateway for llm apps.

it lets you:

why now?

as organizations adopt agentic systems and user-specific ai workflows, identity, policy, and governance become mandatory. shared api keys cannot support enterprise-grade access control or compliance.

a new layer is required — centered around users, not models.

the user-scoped trust and governance gateway

who gatewaystack is for

gatewaystack is built for teams that need user-scoped, auditable, policy-enforced access to ai models — not just raw model access behind a shared api key.

it is especially useful for:

platform & ai infrastructure teams

teams rolling out internal copilots, agent runtimes, or ai-powered tools across the organization. they need to ensure:

security, governance & compliance teams

organizations where regulatory or internal controls matter:

they need “who did what” audit trails, per-user enforcement, pii handling, and policy guarantees.

saas platforms serving many tenants

multi-tenant products that want to:

gatewaystack turns every model call into a user-bound, tenant-aware interaction.

teams building apps sdk- and mcp-powered agents

developers integrating their apps directly into chatgpt or exposing data/tools via mcp:

gatewaystack becomes the unified identity → policy → routing → audit path for all agent interactions.

designing a user-scoped ai trust & governance gateway

the user-scoped trust and governance gateway sits between applications (or agents) and model providers, ensuring that every model interaction is authenticated, authorized, observable, and governed.

gatewaystack defines this layer.

gatewaystack sits between your application and the llm provider. it receives identity-bound requests (via oidc or apps sdk tokens), applies governance, and then forwards the request to the model.

it provides the foundational primitives every agent ecosystem needs — starting with secure user authentication and expanding into full lifecycle governance.

the core modules

CHANGE: Reordered to match execution flow - moved limitabl before proxyabl

1. identifiabl — user identity & authentication

every model call must be tied to a real user, tenant, and context. identifiabl verifies identity, handles oidc/apps sdk tokens, and attaches identity metadata to each request.

📦 implementation: ai-auth-gateway (published)

2. transformabl — content transformation & safety pre-processing

before a request can be validated or routed, its content must be transformed into a safe, structured, model-ready form.

transformabl handles pre-model transformations, including:

this layer ensures that the request entering validatabl and proxyabl is clean, safe, and structured, enabling fine-grained governance and more intelligent routing decisions.

📦 implementation: ai-content-gateway (roadmap)

3. validatabl — access & policy enforcement

once a request is tied to a user, validatabl ensures it follows your rules:

this is where most governance decisions happen.

📦 implementation: ai-policy-gateway (roadmap)

4. limitabl — rate limits, quotas, and spend controls

every user, org, or agent needs usage constraints:

limitabl enforces these constraints in two phases — pre-flight checks before execution and usage accounting after the model responds.

📦 implementation: ai-rate-limit-gateway + ai-cost-gateway (roadmap)

5. proxyabl — in-path routing & execution

proxyabl is the gateway execution layer — the in-path request processor that:

📦 implementation: ai-routing-gateway (roadmap)

6. explicabl — observability & audit

the control plane must record:

explicabl provides the audit logs, traces, and metadata needed for trust, security, debugging, and compliance.

📦 implementation: ai-observability-gateway + ai-audit-gateway (roadmap)

end to end flow

user
   → identifiabl       (who is calling?)
   → transformabl      (prepare, clean, classify, anonymize)
   → validatabl        (is this allowed?)
   → limitabl          (how much can they use? pre-flight constraints)
   → proxyabl          (where does it go? execute)
   → llm provider      (model call)
   → [limitabl]        (deduct usage - optional accounting phase)
   → explicabl         (what happened?)
   → response

each module intercepts the request, adds or checks metadata, and guarantees that the call is:

identified, transformed, validated, constrained, routed, and audited.

this is the foundation of user-scoped ai.

how teams adopt gatewaystack

most teams don’t roll out every module on day one. a common path looks like:

CHANGE: Added note about limitabl’s two-phase operation

  1. start with identifiabl + proxyabl
    • front your existing llm provider with a simple gateway
    • validate oidc / apps sdk tokens and inject x-user-id / x-org-id
    • route requests to the same models you already use
  2. add limitabl and explicabl
    • configure per-user and per-tenant quotas
    • emit identity-level audit logs and cost metrics
    • give security and finance a clear view of “who is using which model and what it costs”
    • note: limitabl runs in two phases (pre-flight + accounting) to both prevent and track usage
  3. layer in transformabl and validatabl
    • enforce content and safety policies before the model
    • apply fine-grained, role-based access to tools and datasets
    • route sensitive traffic to compliant models or on-prem deployments

over time, gatewaystack becomes the shared trust and governance layer for all of your ai workloads — internal copilots, saas features, and apps sdk / mcp-based agents.

example user flow

a finance analyst uses an internal copilot to summarize a contract.

every step is user-bound, governed, and auditable.

error handling

CHANGE: NEW SECTION - Critical for production deployments

gatewaystack modules use a fail-safe strategy based on the security/availability tradeoff:

module on failure reason
identifiabl deny (fail closed) no anonymous requests allowed
transformabl continue (fail open) allow untransformed content with warning
validatabl deny (fail closed) safety first — block when policy engine fails
limitabl (pre-flight) continue (fail open) favor availability over limit enforcement
proxyabl fallback → error try alternative providers, then return error
limitabl (accounting) log error accounting failure shouldn’t block response delivery
explicabl log error audit failure logged but doesn’t block request

circuit breakers: modules that make external calls (jwks validation, policy stores, redis) implement circuit breakers with configurable thresholds.

degraded mode: when upstream dependencies fail, gatewaystack can operate in degraded mode with reduced governance guarantees (configurable per environment).

architecture diagram

app / agent
chat ui · internal tool · agent runtime
→
gatewaystack
user-scoped trust & governance gateway
identifiabl transformabl validatabl limitabl proxyabl explicabl
→
llm providers
openai · anthropic · internal models

every request flows from your app through gatewaystack's modules before it reaches an llm provider — identified, transformed, validated, constrained, routed, and audited.

inputs

outputs

shared requestcontext

CHANGE: Added note pointing to GitHub for full reference

all modules operate on a shared RequestContext object that flows through the pipeline. this context carries identity, content, metadata, and decisions from each module.

📘 full type definitions and integration examples: see docs/reference/interfaces.md in the repo

core types (simplified view):

// shared across modules
export type Identity = {
  user_id: string;
  org_id?: string;
  tenant?: string;
  roles: string[];
  scopes: string[];
};

export type ContentMetadata = {
  contains_pii?: boolean;
  classification?: string[];   // ["sensitive", "financial"]
  risk_score?: number;         // 0–1
  topics?: string[];
  // extensible bag
  [key: string]: unknown;
};

export type ModelRequest = {
  model: string;               // "gpt-4", "smart-model"
  tools?: string[];
  max_tokens?: number;
  messages: any[];
  attachments?: any[];
};

export type PolicyDecision = {
  effect: 'allow' | 'deny' | 'modify';
  reasons: string[];
  modifications?: Partial<ModelRequest>;
};

export type LimitsDecision = {
  effect: 'ok' | 'throttle' | 'deny' | 'fallback' | 'degrade';
  reasons: string[];
  constraints?: {
    max_tokens?: number;
    max_cost?: number;
  };
};

export type RoutingDecision = {
  provider: string;           // "openai", "azure-openai"
  model: string;              // concrete provider model
  region?: string;
  alias?: string;             // "smart-model"
};

export type UsageRecord = {
  input_tokens: number;
  output_tokens: number;
  total_cost: number;
  latency_ms: number;
};

export type RequestContext = {
  request_id: string;
  trace_id?: string;

  identity?: Identity;
  content?: {
    messages: any[];
    attachments?: any[];
  };
  metadata?: ContentMetadata;
  modelRequest: ModelRequest;

  policyDecision?: PolicyDecision;
  limitsDecision?: LimitsDecision;
  routingDecision?: RoutingDecision;
  usage?: UsageRecord;

  // arbitrary module extensions
  [key: string]: unknown;
};

module boundaries

identifiabl

transformabl

validatabl

limitabl (two-phase)

proxyabl

explicabl

integrates with your existing stack

gatewaystack works natively with:

it acts as a drop-in governance layer without requiring changes to your application logic.

getting started

for concepts and architecture: continue reading the module white papers linked above.

for implementation and deployment:
→ quickstart guide
→ deployment guide
→ migration guide

for policy examples and reference code:
→ policy examples
→ reference implementations

want to explore the modules in detail?
→ view the gatewaystack github repo

want to contact us for enterprise deployments?
→ reducibl applied ai studio