One harness, three surfaces, authorization held outside the agent entirely

Salapa lays out a deployment pattern for running one unmodified harness across a terminal, an unattended cron job, and a business-facing chat surface under a single identity, with authorization logic held entirely outside the harness process rather than baked into it. In place of per-operation tool schemas, including MCP, the paper argues for credential-scoped tooling and a call envelope that requires the agent to self-declare risk on each call it makes. Calls flagged as risky are then judged by a fresh model instance rather than graded by the same context that made the call. The paper states plainly that no benchmark accompanies it and that its evaluation is specific to Azure.

Why it matters: This is a pattern for the point an organization has more than one surface running the same agent and does not want a separate permission system for each. The self-declared risk flag paired with a fresh-instance review is a specific, checkable alternative to letting an agent grade its own risky calls, though it is worth noting this is a single-author proposal without an accompanying benchmark.