Repo tools
List, read, and search repository content inside allowed workspace boundaries.
Tool Gateway & Policy Execution
Srasta lets agents act without letting them act blindly.
Enterprise agents need tools: repo reads, file patches, git workflows, shell commands, MCP integrations, and workflow automation. Srasta Tool Gateway puts those actions behind identity, role checks, persona policy, compliance profiles, sandbox limits, human approvals, and audit evidence.
Execution Path
Policy runs before the tool, not after the incident.
Srasta’s Tool Gateway applies layered gates before a request reaches a file operation, git workflow, shell runner, or MCP-backed action. Each gate narrows the blast radius.
Gateway Surfaces
The gateway gives agents useful tools with explicit boundaries.
Srasta separates tool use into surfaces that can be independently allowed, blocked, audited, and scaled. The same policy model can serve direct REST callers and MCP-compatible clients.
File and patch tools
Apply bounded file changes subject to path denylists, patch size limits, and file-count limits.
Git tools
Support branch and merge-request workflows with branch patterns and target-branch rules.
Exec tools
Run allowlisted commands with timeout, CPU, memory, network, and sandbox image controls.
MCP wrapper
Expose Tool Gateway functions to MCP clients while forwarding caller identity and preserving role gates.
Workflow adapters
Connect governed tools to automation systems such as n8n without bypassing execution policy.
Policy Layers
Each layer answers a different risk question.
Authentication
Production mode verifies gateway-signed headers; legacy direct mode supports API keys with optional per-key role.
RBAC
Role gates map caller roles to allowed tool path prefixes before tool-specific logic runs.
Persona gate
Persona allowlists prevent a chat, PM, marketing, coding, or ops persona from reaching the wrong tool family.
Compliance profile
Profiles such as PCI can block sandboxed execution, while FedRAMP posture can require enhanced audit metadata.
Resource policy
Repo allowlists, path denylists, branch rules, command allowlists, timeout caps, and sandbox limits narrow execution.
Approval hooks
Human-in-the-loop approvals pause risky operations, route decisions to configured channels, and auto-reject on timeout.
Human Approval
Approvals exist where risk crosses a threshold.
Srasta’s HITL path can pause high-risk operations before execution, notify an approver, and wait for an approve, reject, or timeout decision. This supports regulated operating models without forcing every harmless read action through the same friction.
Approval channels
Mattermost, Slack, Teams, generic webhook, and SMTP email can receive approve or reject links.
Decision outcomes
Approved operations continue; rejected and timed-out operations are denied by default.
Pending view
The gateway exposes pending approvals for operator dashboards and support workflows.
Future fit
The same approval pattern extends naturally to production apply, reset, credential rotation, and membrane drift decisions.
Sandboxing
Shell execution is bounded by policy and runtime constraints.
Unmanaged agent tools
- Agent can run broad commands with unclear identity.
- Path access is often enforced only by convention.
- Network, CPU, memory, and timeout behavior may be implicit.
- Failure and denied actions are not consistently audited.
Srasta Tool Gateway
- Commands must match allowlisted prefixes.
- Repos must live under allowed workspace paths.
- Sandbox image, network mode, memory, CPU, and timeout are policy-controlled.
- Success, failure, denial, and timeout are emitted as structured audit events.
Audit and Operations
Tool use becomes evidence.
Srasta records the tool, action, caller identity, policy profile, parameters, result summary, success state, error state, and duration. When the hash-chained audit package is present, gateway events are written into the same customer-controlled audit path used by the broader platform.
FAQ
Tool Gateway and Policy Execution FAQ
What is the Srasta Tool Gateway?
The Tool Gateway is the governed execution layer for repo operations, file patches, git workflows, shell execution, MCP clients, and automation tools. It makes tool access identity-aware, policy-constrained, auditable, and optionally approval-gated.
How does Srasta decide whether a tool call is allowed?
Requests pass through authentication, RBAC role gates, persona allowlists, compliance profile checks, repo allowlists, branch rules, path denylists, command allowlists, sandbox limits, and optional human-in-the-loop approval before execution.
Can Srasta work with MCP clients?
Yes. Srasta exposes an MCP wrapper around the Tool Gateway so MCP-compatible clients can use repository, file, git, patch, and execution tools while the gateway still enforces caller identity and policy.
What happens when an action is blocked?
Blocked, denied, failed, timed out, approved, and successful operations are represented as structured outcomes and recorded through the gateway audit path with policy metadata.
Next
Govern tools, then measure whether work got better.
Tool Gateway constrains what agents can do. Measure Loop helps operators understand whether those governed actions produced useful, repeatable, policy-compliant outcomes.