A Mac-only execution gateway in a mixed fleet

A gateway that runs only on Macs can improve a mixed fleet, but only when the pilot has a hard execution boundary. Treating installation coverage as security coverage is the mistake. The useful boundary says which actions must originate on an enrolled Mac, which credentials may exist there, who owns exceptions, and what happens when a Linux or Windows workflow needs the same service.

Partial coverage is defensible when it protects a meaningful slice of risky actions and leaves the rest visibly unchanged. It is indefensible when people believe every agent action passes through the gateway because a few Mac users installed it. A pilot should make that misunderstanding difficult: name the protected workflows, mark unsupported ones, measure action volume, and publish a date for deciding whether to expand, hold, or remove the gateway.

The argument for waiting sounds tidy. A product that runs across the fleet would give every developer the same control. In practice, waiting also preserves the current exposure for an unknown period, and the future product may still require workflow changes. The right comparison is therefore not partial consistency against perfect consistency. It is bounded protection now against the actual controls and delivery date of the alternative.

Partial coverage is a control choice

A partial deployment works when the team chooses the covered actions deliberately and can prove where the control applies. Device count alone tells you almost nothing. Ten Mac users might perform most production administration, while a hundred Linux workstations only build local test code. The reverse can also be true.

Start with the action, not the operating system. An execution gateway controls a call at the point where it runs and obtains authority. Ask which HTTP requests, SSH commands, and other external actions deserve a credential boundary, an approval, or an audit record. Then identify the machines and people from which those actions currently originate. That sequence prevents the fleet inventory from dictating the security model.

The pilot boundary should have four parts:

• named people or roles that may use the gateway;
• named action classes that must pass through it;
• named credentials that move into the controlled store;
• named workflows that remain outside, with an owner for each exception.

The fourth part matters most. An exception is not merely a missing installation. It is a documented route that still uses the old credential and control model. If nobody owns that route, the pilot creates a blind spot dressed up as progress.

Do not tell the company that the gateway "covers the Mac fleet." Say that it covers, for example, production SSH from the release group and deployment API calls from two agent workflows when those run on enrolled Macs. That statement is narrower, testable, and hard to misread. A skeptical reviewer can ask for the relevant logs, credential inventory, and exception list instead of debating what "coverage" means.

This precision also controls what governance teams may conclude. Evidence from a bounded pilot can support a claim about the named actions during the named review window. It cannot support a claim that agent credentials across the company now receive the same protection. Put the scope statement beside every metric and audit export so a chart does not travel farther than its qualifications.

Partial coverage can still reduce serious exposure. If one deployment credential no longer enters an agent process, that change remains real even when another platform uses the old route. The honest claim is smaller than a fleet program, but it is stronger than an enrollment total that cannot connect devices to actions.

People, actions, and credentials define the pilot

A useful pilot boundary names people, actions, and credentials together because any one of those dimensions can route around the control. A list of Mac users without actions allows an enrolled user to keep calling a sensitive API directly. A list of APIs without credentials allows an old token to remain in a Linux environment. A credential list without people leaves ownership unclear.

Choose a group whose work is important enough to test the control but small enough to observe closely. Release engineers, infrastructure maintainers, and developers who run autonomous coding agents against staging systems are common candidates. Avoid selecting volunteers only because they already like new tools. Their workflows tend to be cleaner than the awkward cases that decide whether the gateway will survive.

For each included workflow, record the precise action boundary. "Cloud administration" is too broad. "The deployment agent calls the release endpoint with the production bearer credential" is useful. "Server access" is too broad. "The duty engineer opens production SSH sessions from an enrolled Mac" gives an auditor something to check.

Credential placement completes the boundary. Once a credential moves behind a gateway, copies in shell profiles, environment files, agent configuration, password managers used for injection, and CI variables can defeat the result. The pilot needs a removal task for every prior copy it can safely retire. If a Windows build still needs the credential, record that dependency instead of deleting it and discovering the break during a release.

Specify the channel as well as the destination. An HTTP call made through a gateway does not imply that a vendor command line client, browser session, database driver, or local SSH tool follows the same path. Two tools can reach the same service with different credentials and leave different evidence. Treat each route as a separate action until testing proves they share the control.

Agent configuration deserves its own check. A repository may define the approved gateway as the normal MCP tool while a user profile still exposes a direct shell command or environment token. The agent will choose whichever route its instructions and tools make available. Remove the direct capability for included actions, or document why it remains and how reviewers will distinguish its use.

The boundary document should fit on one page before its supporting register. It should state the pilot group, start and review dates, included actions, credential owners, approval expectations, evidence location, and explicit exclusions. If the main statement needs a diagram and six footnotes, the scope is probably not settled.

A good test is whether a substitute duty engineer can answer two questions without asking the pilot designer: "Must this action use the gateway?" and "What approved route exists from my current machine?" If either answer depends on oral history, the pilot is not ready.

Request origin and execution origin are different

The machine where a person or agent starts work does not have to be the machine where the privileged action executes. Teams often blur request origin with execution origin, then conclude that a Mac application cannot help a Linux or Windows user. That conclusion may be correct for an interactive local workflow, but it is not universally correct.

Consider a developer on Windows who asks an automation service to deploy a build. The request starts on Windows. If a controlled Mac receives a constrained job and performs the deployment call, the execution boundary sits on that Mac. The developer does not need the production credential. The design can extend action coverage beyond the desktop count, provided the handoff has strong identity, narrow inputs, and an audit trail.

That pattern has limits. A shared Mac must not become a general remote command box. If callers can submit arbitrary shell text, upload executables, or choose any destination, the team has moved the original credential risk into a powerful relay. The remote interface should expose a small action vocabulary, validate every input, bind requests to an identity, and reject anything outside its purpose.

The identity crossing the handoff must survive into the record. Logging only the shared Mac account tells an investigator where execution happened but not who requested it. The request record should connect a person or workload identity, the allowed action, its important inputs, the approval decision, and the resulting call. Otherwise, delegation increases action coverage while weakening accountability.

Availability becomes part of the security decision too. If all delegated releases depend on one employee's laptop, routine sleep, travel, or repair can trigger emergency bypass. A pilot may accept that limit for an infrequent staging action. Production use needs an availability plan that does not turn personal Macs into an informal server fleet.

Latency and human approval also change the answer. A Windows user who needs an interactive SSH terminal cannot transparently borrow a Mac menu bar session without designing a remote access path. A background deployment action may tolerate a short queue and an approval. A local debugging loop that makes fifty small authenticated requests probably will not.

This distinction gives the pilot three honest categories. Direct coverage means the action originates in a supported local workflow. Delegated coverage means another platform requests a narrow action that executes inside the boundary. No coverage means the action and its credential remain outside. Keep these labels separate in reports. Calling delegated execution "Windows support" would hide the architecture and create expectations the pilot cannot meet.

Unsupported workflows need a public register

Document every unsupported workflow before credentials move, because the migration itself will expose hidden dependencies. The register is a working control, not a disclaimer stored in a project folder. Developers, support staff, security reviewers, and incident responders should know where to find it.

Use entries that describe real routes:

• A production release starts on macOS, calls the deployment API, has direct coverage, and belongs to the release lead until the pilot review.
• An emergency database session starts on Linux, reaches production over SSH, keeps its existing access process, and returns to the database lead when a Linux option is tested.
• Package publication starts on Windows, uploads to a registry with existing token handling, and stays with the build lead until the workflow moves or a suitable client ships.
• A staging restart starts in Linux CI, calls a service API, and remains a delegated candidate owned by the platform lead until its narrow interface passes review.

Status needs a fixed vocabulary. "Investigating" can conceal a permanent gap. Use direct coverage, delegated coverage, no coverage, and retired. Add "blocked" only when the pilot itself prevents required work, and treat that state as an incident with an owner and deadline.

The current control field prevents a damaging assumption: outside the pilot does not mean uncontrolled. A Linux production session might already require temporary credentials and peer approval. A Windows publishing token might sit in a managed build service. Record those facts, then compare them with the gateway on their merits. The pilot should not claim credit for controls it did not create or dismiss controls that already work.

Publish unsupported cases near the setup instructions. When a user on an unsupported machine encounters an article that simply says "install the gateway," they will improvise. They may copy a credential from a teammate, route an agent through an unreviewed host, or disable the new path for everyone. A visible register gives them an approved answer, even when that answer is "continue using the existing process until this trigger occurs."

Give each entry a detection method. A destination audit field, source address, credential identifier, or command record may distinguish the route. If a row has no observable signal, say so and fix that gap before treating reconciliation as proof. A register full of routes that nobody can recognize after execution is only an inventory.

Review the register after any team move, credential rotation, new agent deployment, or change in duty ownership. Fleet percentages drift slowly; workflows can cross the boundary in one pull request.

Silent crossover breaks a pilot

A pilot fails when a covered workflow silently falls back to an uncovered route. The failure often looks harmless because the work still completes. The audit record, approval, and credential boundary disappear, while the success signal stays green.

Suppose a release engineer normally launches an agent on a Mac. The agent sends the deployment request through the gateway, which holds the production token and records the call. During an incident, the engineer connects to a Linux workstation because the Mac is unavailable. The same repository contains a fallback script that reads DEPLOY_TOKEN from the environment. A teammate places a token in the shell so the release can proceed.

The deployment succeeds. The team now has one action in the service log, no corresponding gateway record, a production token exposed to the agent process, and an undocumented copy in shell history or configuration. If the review counts successful deployments from Mac users, it reports coverage. If it reconciles sensitive service actions against gateway activity, it finds the gap.

The immediate lesson is not "ban Linux during incidents." Incident work needs reliable alternatives. The lesson is to define fallback before pressure arrives. The team could keep the existing Linux process as an explicit exception, require a separate incident approval, and record its use in the exception register. It could also provide a narrow delegated deployment action executed on an enrolled Mac. Which answer fits depends on availability requirements.

Test crossover intentionally. Run an included workflow from an unsupported machine, with the gateway locked, after the agent process restarts, and while the designated Mac is offline. The expected result must be one of three things: a clear denial, a documented alternate route, or a recorded exception. Success through an unknown fourth route is a pilot defect.

Credential discovery belongs in the same test. Search the relevant repository configuration, developer setup instructions, CI variables, and local environment for the retired credential name. Do not copy secret values into a report. Record each location, owner, and removal decision. The exercise often finds more risk than the installation itself.

Measure action coverage instead of fleet coverage

Measure the fraction of included sensitive actions that used the intended route, plus the exceptions, denials, and fallbacks around them. "Twenty percent of laptops enrolled" is an operations metric. It does not say whether the gateway protected one trivial test call or every production deployment.

Define the denominator before the pilot starts. A practical denominator is the set of actions named in the boundary document during the review window. Count evidence from the destination service when possible, then reconcile it with gateway records and approved exceptions. Gateway logs alone cannot reveal actions that bypassed the gateway.

Destination records can have gaps too. A service may record the credential identity and time but omit the originating person, or aggregate several operations into one job. Test the join before promising exact reconciliation. Document which fields connect the records, the acceptable time window, duplicate handling, and who investigates an unmatched action.

Sampling is useful for discovering workflow types, but it is weak evidence for a small set of consequential actions. Missing one unauthorized production deployment matters more than estimating an average. For the included action set, prefer complete reconciliation. If the destination cannot provide it, state that limitation in the pilot result rather than converting a sample into a coverage claim.

Track a small set of measures:

• covered actions matched to a gateway record;
• approved actions taken through documented alternate routes;
• sensitive actions with no matching record or exception;
• denials caused by the boundary working as designed;
• blocked tasks where no usable route existed.

Interpret denials and blocks separately. A denial can prove that a locked vault or missing approval stopped an unauthorized call. A blocked task means an authorized person could not complete required work. Combining them rewards a control for hurting availability, or punishes it for correctly refusing access.

Device data still has a place. It explains who could use direct coverage and where training or installation failed. Pair it with action data rather than presenting it as the security result. The useful sentence is: "Eight of ten eligible Mac users enrolled, and 94 of 100 named deployment actions used the controlled route; four used approved incident fallback, and two have no match." If you cannot support exact numbers, report the actual records without inventing a percentage.

Also measure operator cost. Count repeated approval interruptions, time spent diagnosing platform gaps, exception volume, and recovery time when the execution Mac is unavailable. A control that catches risky calls but trains users to approve blindly needs redesign. A control that protects a small action set with little friction may deserve expansion even if most company devices cannot run it.

Give the pilot owners and stop conditions

A pilot needs structured scope, responsible owners, and stop conditions so it cannot become permanent by neglect. The configuration below is a documentation artifact, not a policy engine. Store it beside the pilot runbook, review changes like code, and use it to generate the readable register if that reduces drift.

pilot:
  name: agent-action-gateway
  starts: 2026-08-03
  review_by: 2026-09-14
  owners:
    security: sec-platform
    operations: release-engineering
  included_actions:
    - id: production-deploy
      origins: [enrolled-macos]
      credential_owner: release-engineering
      fallback: incident-release-process
  unsupported:
    - id: production-ssh-linux
      owner: infrastructure
      current_control: existing-access-process
      revisit_when: supported-execution-path-tested
  stop_if:
    - undocumented-credential-copy
    - required-work-has-no-approved-route

Use dates that force a decision. "Review quarterly" is weak because nobody knows which meeting owns it. The review should have a named chair and three possible outcomes: expand the included action set, hold the boundary while specified gaps are resolved, or remove the pilot and restore the documented prior process.

Stop conditions deserve the same attention as success criteria. Pause credential migration if a required Linux or Windows task has no approved route. Stop the affected workflow if the gateway creates an uncontrolled remote execution path. Investigate immediately when destination service evidence shows an included action without a gateway record or registered exception.

An exit does not prove the idea was bad. It may show that the selected workflow depended on local tools, availability, or platform reach that the pilot design ignored. Preserve the register, reconciliation results, and operator notes. Those artifacts make the next product comparison much sharper than a vague report that users "did not adopt."

Assign one owner to exception aging. Without that role, temporary credentials and fallback scripts survive after the reason for them disappears. The owner does not need authority over every team, but must have authority to request evidence, schedule reviews, and escalate overdue decisions.

Waiting has a cost that belongs in the comparison

Compare partial coverage now with an option for all platforms later by scoring current protection, unsupported work, operational cost, and credible delivery timing. Do not compare a running pilot with an imagined product that has perfect parity, zero migration effort, and no release date.

Waiting is reasonable when the protected action volume is tiny, Mac execution would create a fragile relay, or the planned alternative already has a funded owner and testable release plan. Waiting can also win when existing controls already keep credentials away from agents and produce the approvals and evidence the team needs. Installing another boundary would then add ceremony rather than reduce exposure.

Partial coverage is reasonable when Mac users perform a concentrated set of sensitive actions, the old credential copies can be retired for that set, and unsupported workflows can continue under known controls. It becomes stronger when the pilot produces evidence that the team can compare with destination logs. It becomes weaker as delegated execution grows into a general remote service or as exceptions require shared persistent credentials.

Put claims about the future option in writing. Record supported operating systems, action channels, credential model, approval behavior, audit export, migration work, named owner, and the next verifiable milestone. "We expect Linux soon" is not a plan. Neither is "the vendor is working on it." A branch, build, contract commitment, or scheduled acceptance test gives the claim weight.

Include migration cost on both sides. The Mac pilot may require agent configuration changes, credential cleanup, user training, and a fallback runbook. The future option will not arrive without integration, acceptance testing, and another credential move. Count work that has an owner and estimate, and label the rest unknown. A zero beside an unplanned migration is fiction.

Delay should have a review date just as a pilot does. If the alternative misses its milestone, the team should reconsider the actions left exposed rather than rolling the decision forward automatically. Waiting without a trigger turns a product preference into an indefinite security exception.

Use the same workflow register to evaluate both choices. For each row, write what changes under the pilot, what changes if the team waits, and what remains exposed in either case. This prevents platform parity from swallowing more important differences. A product can run everywhere yet still hand secrets to an agent. Another can keep secrets out of the process but cover only one execution host.

Set a decision date based on risk and evidence, not enthusiasm. At that meeting, the team should be able to say which sensitive actions gained a boundary, which did not, what the control cost operators, and whether the alternative became more concrete. If those facts are missing, extending the pilot only extends uncertainty.

Sallyport fits only inside an honest boundary

Sallyport can support this kind of Mac pilot because its app keeps API and SSH credentials in an encrypted vault, executes actions for MCP-capable agents, applies its fixed approval ladder, and records sessions and calls in a hash-chained encrypted log. It does not turn a mixed fleet into a deployment across every platform, so the boundary must describe the exact Mac execution paths that use it and leave every other path in the unsupported register.

The first pilot action should be narrow enough to reconcile end to end. A production deployment call is a better candidate than "all agent networking" because the team can name its credential, destination, callers, expected frequency, fallback, and destination records. Move that credential behind the gateway for the enrolled group, remove obsolete copies that no uncovered workflow needs, then test denial and fallback behavior.

Do not route every Linux and Windows request through a shared Mac merely to improve a coverage chart. Delegation earns its place when the remote action has a small input surface, authenticated callers, bounded authority, dependable availability, and records that connect the requester to the executed call. Otherwise, retain the existing process and label it clearly.

At the review date, expand only if the records support it. A successful pilot has few unexplained actions, usable fallback during failure, manageable approvals, and exceptions that owners actually review. A failed pilot has taught the team something equally concrete: where execution really originates, which credential copies persist, and why one operating system cannot carry that workflow safely.

Mixed fleets rarely become uniform because a security project asks nicely. The durable result is a boundary that remains true on an ordinary day and during an incident. If the pilot cannot state that truth in one page and prove it by reconciling actions, stop calling it coverage.