The best control point is the function that can create impact
A gateway or backend already knows facts that a distant content filter cannot: the authenticated user or workload, the agent making the request, the real tool, the final sanitized arguments, the destination, and the credential about to be used. That is the context needed for a meaningful authorization decision.
The TypeScript SDK makes those facts part of a tenant policy request immediately before execution. It then gives the service a clear contract: continue with the allowed action, stop on denial, verify delegated work at the receiving boundary, and review configured output before it leaves the service.
What changes when AgenticDome is in the path
The protected dispatcher calls AgenticDome with the final actor, agent, action, arguments, purpose, destination, and correlation context. Only an allowed decision reaches the real local function or outbound client. Delegated execution is verified where the specialist acts, and configured output is reviewed before return or storage.
Why TypeScript platform teams use AgenticDome
AgenticDome adds agent-aware policy to the service layer teams already trust with credentials and network access. It complements API authorization by deciding whether this agent action is appropriate in its current business context.
Decide at the last responsible moment
Authorize the final tool, sanitized arguments, destination, method, and workload immediately before the code path that creates impact.
Cover custom infrastructure
Use explicit typed calls in API middleware, MCP gateways, queues, workers, agent coordinators, and bespoke backends that do not share one framework lifecycle.
Bind delegation to execution
Require the downstream specialist to verify that source, target, session, tool, and arguments match the authorized handoff before acting.
Bind high-impact egress
Where the brokered gateway mode is enabled, attach short-lived enforcement headers to the actual outbound request rather than a disconnected pre-check.
Add policy without replacing the service
Install agenticdome-sdk, construct the client with the assigned regional or Sovereign sidecar, and add the decision call to the dispatcher that already owns execution. Existing schema validation, API authorization, transport, rate limiting, and observability remain in place.
How AgenticDome creates the control point
1. Request ingress
Screen input and bind authenticated user/workload, tenant, agent, purpose, and correlation context.
2. Tool authorization
Pass the exact tool, sanitized arguments, version/digest, and destination where applicable.
3. Delegation
Authorize manager-to-specialist work and verify the matching decision before execution.
4. Output review
Call Mesh validation before returning or storing configured sensitive content.
5. Real execution
Attach broker headers to the actual outbound request, not a simulated callback.
What this changes for real teams
Protect the route that holds the credential
“Our agent reaches internal business APIs through a Node.js service; authorization must see the exact request we are about to send.”
AgenticDome contribution: Call guardrailValidate() immediately before dispatch with the real actor, agent, tool, sanitized arguments, purpose, and destination. Server authorization, schemas, limits, and least-privilege credentials remain intact.
Govern forwarding without replacing transport
“We want policy before an MCP tool call and review after it returns, but our gateway already owns a reliable transport.”
AgenticDome contribution: Use the explicit TypeScript MCP preflight and Mesh output calls around the existing tools/call forwarder, retaining the transport while making the forwarding decision tenant-governed.
Make the receiving worker verify authority
“A queue message from an upstream service should not be enough to authorize a high-impact specialist action.”
AgenticDome contribution: Use A2A authorization and verification at the specialist boundary with stable tenant, session, source, target, tool, and argument context before the downstream worker executes.
The risks this helps contain
| Risk | Why it matters | Public AgenticDome control |
|---|---|---|
| Middleware bypass | An alternate route can call the raw executor or API client. | Centralize dispatch through the protected function and test direct-route denial. |
| Argument substitution | Arguments can change between authorization and execution. | Authorize the final sanitized arguments at the last responsible moment and bind version/digest/destination where supported. |
| Delegation replay or mismatch | A prior approval can be reused for a different specialist or action. | Verify and consume the decision against the matching tenant, session, source, target, tool, and arguments. |
| Sensitive output | API and tool responses can contain secrets or regulated identifiers. | Review configured content with meshValidate() before return or storage and preserve source-system DLP. |
| Broker receipt misuse | A receipt checked away from the real network call does not protect execution. | Apply enforcement headers to the actual destination/method request through the configured gateway. |
A practical path to production
Map the dispatcher
Identify the final service function that holds credentials or sends the external request.
Use typed context
Pass real actor, agent, tool, arguments, destination, version, digest, and correlation fields.
Fail deliberately
Select and test the outage posture appropriate to each action’s impact.
Test the physical path
Prove that allowed, blocked, replayed, mutated, and output-review requests use the intended sidecar.
Where this control ends
The TypeScript SDK protects explicit calls made by application code. It does not automatically wrap arbitrary Node.js frameworks, inspect code running in remote providers, replace API authorization or schema validation, or govern a request sent through a path that never calls the SDK. Broker enforcement additionally requires the configured gateway and actual outbound headers.
Current lifecycle note
Use the npm package version, README, generated types, and tests corresponding to the deployed release. MCP and broker patterns are explicit examples, not a claim that every protocol or framework route is patched automatically.