The test ends with a simple assertion: shell_executed is still False.

An agent has just read an external web page. Next it requests a local shell command that would read an SSH private key. In the test, the command never runs. The tool call is stopped at the web-to-host boundary, and the security event records the attempted crossing without reproducing the key path or the malicious page text.

This is not a story about someone breaking into my machine. It is an adversarial regression test in Mac MCP, the macOS agent execution layer I work on. I think that distinction is important. A passing test establishes something specific about the implementation under those conditions. It does not turn an agent into a sandbox or prove that every prompt-injection variant has been handled.

The problem was not whether the agent could call a tool

For a conventional app, permissions often look like a table: this user can read, that process can write, this operation is restricted.

An agent complicates that model because the next action may be influenced by material it has just consumed. The user might have authorized a developer workflow. The model might be capable of calling a shell tool. Neither fact gives a random page the authority to decide what should happen on the user’s Mac.

That is the boundary I wanted to keep visible: tool capability is not the same thing as an instruction’s authority.

In Mac MCP, the policy is evaluated with more than the tool name. The server also tracks where the current execution context came from. After an agent reads a third-party browser page, its logical session can carry a provenance marker called tainted_untrusted_web, along with the source origin.

When that session requests a privileged host operation, the server evaluates the crossing separately from the general permission profile. Under non-trusted or scoped developer workflows, the gate may demand a local, source-aware Allow Once decision. If approval is unavailable or denied, the operation does not run.

The page may still be useful. The agent can summarize it, extract details, navigate, and continue its browser work. What it cannot silently do is turn the page’s instructions into authority over the machine.

I tested the boundary, not just the error message

One regression test sets up a browser observation from an untrusted origin and then attempts a shell call. The expected error is web_host_boundary_approval_required. More importantly, the test checks that the shell callback was never invoked.

That second assertion matters. I have seen enough automation systems report a failure after producing a side effect. A denial message is nice. Proof that the action did not happen is the actual result.

The test also checks the security event. It records the boundary crossing, but it must not contain the private-key filename, the token-like query string, or the page’s injected instructions. Logging a rejected security event should not create a second route for exposing the information we tried to protect.

The next test answers a different question: what happens when a person deliberately approves an action?

Allow Once should mean once

A broad permission switch is convenient, but it can quietly become an invitation to reuse authority later. Mac MCP’s escalation grants are tied to an action fingerprint, the tool, the logical session, and the source origin. They have a short lifetime and one remaining use.

In the regression test, a local grant permits the selected shell action. The next shell request is denied again. A separate test moves from one external origin to another and verifies that the earlier grant no longer applies.

That behavior is more useful to me than a vague “agent has been approved” label. If I approve one operation after seeing which page led to it, I have not approved every operation the agent might imagine afterward.

The browser can change without becoming trustworthy

A subtler case starts with an untrusted site, then opens a localhost page.

It would be tempting to look only at the current URL and declare the session safe again. But the agent may still be carrying the earlier page’s content in its context. Reading a local dashboard does not erase the influence of the third-party page it read first.

The corresponding test checks that the untrusted provenance survives this transition. The current origin can become local while the session remains web-scoped, and a privileged host request still hits the boundary.

This is also why copying untrusted page content into a scratch file should not automatically make it trustworthy. Changing the container of some text is not the same as changing who gets to instruct the agent.

The exception I would not hide

There is an important limit to this explanation. Mac MCP has a global trusted profile that intentionally skips the routine web-to-host confirmation. It is designed for a different trust and interruption trade-off. The implementation and tests say so explicitly.

Sensitive data leaving the machine for an untrusted origin is a separate, source-aware check, including in trusted mode when a secret is detected. But detection is not a guarantee against arbitrary transformations, and approval prompts are not a replacement for operating-system isolation.

I would rather state that caveat than market the system as if every powerful tool call were universally blocked behind a confirmation.

What this changed in my review process

I now look for three different answers when checking an agent’s permissions.

First, is the tool capability allowed under this execution profile? Second, where did the instructions or data influencing this action originate? Third, if someone approved an exception, what exactly did that approval cover, and how was the eventual side effect verified?

Those questions produce better tests than “Can the agent use the terminal?” They force me to check the transition between contexts, the execution callback, the reuse of permission, and what the logs disclose.

The most useful part of this work was not a smarter prompt. It was putting the decision where the action is enforced, rather than asking the model to remember an informal rule.

My agent may have permission to use the shell. The web page it just read does not get to decide when.

Source and verification: Mac MCP repository (https://github.com/bulutarkan/mac-mcp); implementation in mcp_server/security_context.py and mcp_server/observability.py; regression tests in tests/test_security_boundaries.py; permission semantics in docs/safety.md. I verified the relevant WebHostBoundaryRegressionTests against the current source. These are constructed tests, not claims of a live compromise.

Author’s note: This article was prepared with AI writing assistance. Its technical descriptions were checked against the Mac MCP source code and regression tests.

My AI Agent Had Permission to Act. That Didn’t Mean It Should. was originally published in ThreadSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.

I ran into this distinction while working on the native chat window for Mac MCP, an open-source macOS automation project I maintain. The app lets me follow coding agents as they use the terminal, browser and desktop. The interface reads messages from a local server, and when possible it follows an event stream instead of repeatedly fetching the entire conversation.

Silence has more than one meaning in an agent interface. The agent might be thinking, a tool might be waiting, the Mac might have gone to sleep, or the stream may simply have ended. If the window displays a green “Live” status after every successful HTTP request, it can look healthy without actually receiving the updates it promised.

A poll answers one question. A stream answers another.

I separated those questions in a small state model called ChatLink. It recognizes three states: live, reconnecting and offline. Those names are simple, but the transitions matter more than the labels.

When the event stream opens successfully, the state becomes live and consecutive failures reset. When that stream drops, the app immediately moves from live to reconnecting. It retries with a bounded increasing delay rather than hammering a server that might be restarting or a machine that has just woken up.

During the interruption, the chat still performs an HTTP poll to catch up on anything it missed. That poll matters. It can tell us the local server answered and return transcript changes since the last cursor. But when the app is configured to use an event stream, a good poll does not set the status back to live. Only an opened event stream does that.

Without this distinction, the interface could say the connection recovered just because one fallback request succeeded. The actual streaming channel might still be disconnected. A correct-looking green badge could hide a broken live subscription.

It was tempting to use a Boolean called connected. That would have been less code, but it would collapse different kinds of evidence into one reassuring word.

The failure count is tied to actual outcomes, not elapsed time. Three consecutive failures can move the indicator to offline. A successful poll while the stream is down can move offline back to reconnecting, which means the server is answering again, not that streaming has recovered. In a configuration without streaming, polling really is the connection, so a successful poll is enough to mark it live.

Those distinctions keep the status honest rather than merely optimistic.

I added a Retry action for the person using the Mac. It resets the failure count, cancels the current follower task and starts following the selected chat again. That does not pretend to fix the network or restart a failed agent. It just gives the user a bounded way to ask for another connection attempt instead of waiting for the backoff delay.

The cursor matters as much as the label. After a drop, the chat polls for changes since the last known cursor, then resumes listening for new events. Without catch-up, an interface might look connected but silently lose the part of an agent's response produced during the interruption.

There is another failure path I treated separately: sending the user's own message.

Imagine typing a detailed instruction with attachments. The send request fails, and the app clears the composer. Now the user has to reconstruct a prompt that took minutes to write. This is a more visible failure than a temporary red status label.

Mac MCP keeps failed sends with the chat they belong to, including their text, attachments and error reason. It restores the original draft automatically only when the person is still in that chat, the composer is empty and no new attachments have been added. If someone has begun writing a newer message, the failed text must not overwrite it.

That rule is intentionally conservative. It is better to show a failed send that can be retried or discarded than to destroy newer input while trying to appear helpful.

The code for connection states, draft restoration and attachment safeguards is in ChatReliability.swift:
https://github.com/bulutarkan/mac-mcp/blob/main/menu_app/Sources/ChatReliability.swift

The event-following and polling loops are in ChatWindow.swift:
https://github.com/bulutarkan/mac-mcp/blob/main/menu_app/Sources/ChatWindow.swift

I separated these rules from the window layout so they could be tested as plain logic. The repository has tests for stream drops, successful fallback polls, repeated failures, manual retries and whether a failed send is safe to restore into the composer. Those tests are useful because they exercise state transitions without requiring me to reproduce a laptop waking from sleep at exactly the right moment.

This isn't a claim that every interruption is solved. Real networks fail. Processes restart. A cursor-based catch-up mechanism still depends on what the server retains and returns. But a user interface can be precise about what has actually recovered, which is a smaller and more defensible promise.

I keep finding the same lesson in agent tooling: a successful operation is not always the success the person asked about. HTTP 200 is not necessarily a working live stream. A recovered connection is not necessarily a recovered message. And a retry should never silently erase work the person has already done.

The status indicator is a small detail. The contract behind it is not.

A successful poll did not mean my agent’s live connection was back was originally published in ThreadSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been building a team runner for coding agents in Mac MCP, a project that lets agents work with local macOS tools. The basic idea is familiar: one task finishes, another depends on its output, and a lead agent keeps the pieces moving. The less familiar part is what happens when the timing doesn’t cooperate.

I was working through the team-message and dependency code when a simple boundary case became hard to ignore. A teammate can finish its task before another agent sends the clarification it needed. The message can be valid, the sender can be authorised, and the recipient can still be gone.

If the messaging tool says “sent,” what exactly does that mean?

It doesn't mean the finished agent read it. It doesn't mean the agent will run again. And it certainly doesn't mean the clarification changed the artifact the agent already produced.

Completion is not an inbox

In the first version of the hand-off, a finished agent could simply leave its team room during cleanup. That's a reasonable lifecycle decision until you ask what should happen to the next message addressed to it.

The tempting fix is to keep the mailbox around and report success for every send. But an inbox that can store a message is not the same as a worker that can act on it. That difference becomes important when a person or another agent thinks a correction has been applied.

I changed the way the runner handles the end of an agent's life. Finishing a member is now an explicit state transition, not just leaving a room. When a message is addressed to someone already finished, the sender is told that the target is no longer active. The message is passed to the lead and any unfinished dependent tasks that can still use it.

There's also a distinct correction message kind. That matters because a change to a previous answer is not just another progress update. I want a future reader to be able to tell the difference between “I have more information” and “The thing I told you before needs correcting.”

The policy here is deliberately modest. The runner doesn't resurrect a finished process and replay its last step. Doing that could create duplicate file edits, external requests or other side effects. It routes what it can and reports what it couldn't do.

A dependency needs the actual result

A second problem was sitting nearby. A dependent task might know that a predecessor has completed without having enough of its result to make the next decision. Giving every teammate unrestricted access to every other agent's transcript would solve the convenience problem and create a new access-control problem.

So I narrowed the rule instead. A team task can read the completed result of a task it explicitly depends on or has been assigned to review. That relationship is checked when the result is requested. Unrelated agents don't automatically inherit access just because they happen to belong to the same team.

The prompt for the dependent task explains how to fetch the result. I wanted the capability to be discoverable at the point it matters, not buried in an API description that an agent may never inspect.

There is an uncomfortable trade-off. A full predecessor result is often more useful than a neat two-sentence summary. It's also more information. The dependency relationship is therefore the authority boundary, not membership of the wider team.

Fail before you spawn

These message changes led me back to a separate rule in the team runner: validate every team and task setting before starting anything.

If an agent team definition has an invalid setting, launching the first two agents and discovering the third is invalid is a lousy outcome. Now the preflight can return all of the setting problems in one response and start none of the team. If a task cannot start, its dependents are skipped rather than left waiting for a result that will never arrive.

This isn't only about helpful error messages. Partially starting a workflow means some work may already have changed files or contacted a service. Rejecting an invalid plan before launch is safer than explaining afterward why half the plan ran.

It also makes testing less ambiguous. For a rejected team definition, the useful assertion isn't only that the API returned an error. It's that no agent was created. For a blocked dependency, the assertion isn't only that the dependent task didn't succeed. It's that the runner deliberately skipped it with a reason.

You need history to debug the hand-off

The final part of this work was making the team conversation readable afterward. Messages now have a history view, including information about who was shown a message and who opened it. The owner can inspect that history from the app's team settings.

This doesn't prove a recipient understood a message. An opened marker is an observation, not comprehension. But it's better than looking at two agent summaries and guessing why the second one didn't use a correction sent by the first.

I kept the distinction between the transport event, the recipient's state and the downstream effect. If a teammate was already finished, that should be visible. If another agent received the correction, that should be visible too. If the correction never affected the completed output, a tidy “sent” badge shouldn't conceal it.

These are changes to the runner and its tests, not a claim that I’ve solved every asynchronous-agent problem. Long-running teams, retries and external side effects still make message timing difficult.

What changed for me was the definition of a successful hand-off. It isn’t enough for the message to leave the sender. Somebody who can still act on it must receive it, and the system must be able to say when that did not happen.

The implementation behind this change is in the Mac MCP commit: https://github.com/bulutarkan/mac-mcp/commit/64e0864c5329aafffe57984fe9abaf55e40a00ae

My agent finished before its teammate could read the message was originally published in ThreadSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everything worked smoothly — until Producer A needed to change a single field.

Suddenly, your “independent” microservices felt like they were chained together. If you have ever been stuck in a deployment deadlock because of shared DTOs, this story is for you.

1. The Golden Cage of Shared DTOs

When building distributed systems, you quickly run into a classic problem: If the producer changes the message format, the consumer crashes.

To prevent production issues, teams usually choose the most obvious solution: The Shared DTO Library.

We create a common library (a shared Maven or Gradle module) that holds all data classes. Both the Producer and Consumer add this library as a dependency:

[Producer] --> (uses common-dto.jar) --> [Kafka Topic] --> (uses common-dto.jar) --> [Consumer]

At first, this feels like clean engineering. The Java compiler protects you. If a developer renames a field in the producer without updating the shared module, the code simply will not compile.

It looks safe. But in reality, you have built a golden cage.

2. The Hidden Cost of Tight Coupling

As your system grows and more teams join, serious problems begin to appear:

• Deployment Lock (Dependency Hell): A simple change turns into a long coordination meeting. If Team A wants to add a new field, they cannot just deploy their service. They must first update the shared library, release a new version, wait for Team B to update their dependencies, test both services, and deploy together.
• The Illusion of Independence: Your architecture diagram shows microservices, but your codebase is still a monolith tied together by a shared .jar file.
• Compile-Time Safety vs. Runtime Agility: You get safety during compilation, but you lose the freedom to deploy services independently.

We realized the core mistake: We were relying on a code-level contract instead of a data-level contract.

3. Enter Apache Avro and Schema Registry

To break this chain, producers must be able to change their data models without breaking consumers, and without forcing lock-step deployments.

This is where Apache Avro and a Schema Registry come in.

Instead of sharing compiled Java classes, teams share a clear, language-neutral schema file (written in JSON format, with a .avsc extension).

{
  "type": "record",
  "name": "UserEvent",
  "namespace": "com.example.events",
  "fields": [
    { "name": "userId", "type": "string" },
    { "name": "regionCode", "type": ["null", "string"], "default": null }
  ]
}

How does it work without a shared library?

Each team keeps its own project completely separate. During the build step, the Avro Maven/Gradle plugin reads the schema and generates local Java classes inside each service.

There is no shared JAR dependency. Each service owns its code, but both honor the same data contract.

4. The Real Superpower: Schema Evolution

The best feature of Avro is not just small message size or fast binary serialization — it is Schema Evolution.

When Producer A needs to add a new field, it updates the schema to version 2 (v2) and registers it with the Schema Registry.

Does Consumer B need to update and redeploy immediately? No.

Here is the exact mechanism that prevents production crashes:

1. Producer writes with v2 (Writer Schema): Producer A sends the message with the new field (and a small header containing the schema version ID).
2. Consumer reads with v1 (Reader Schema): Consumer B is still running on the old code. It has not been updated or redeployed.
3. Automatic Schema Resolution: When Consumer B receives the message, Avro compares the Writer Schema (v2) against the Reader Schema (v1). Because the new field has a default value, Avro simply ignores the new field for Consumer B and fills the data into Consumer B’s existing v1 class.

Consumer B continues to run without crashing, without code changes, and without downtime. The team responsible for Consumer B can update their code whenever they are ready — next week, next sprint, or never (if they do not need that new field).

• The Gatekeeper: What if Producer A makes a dangerous change (like changing a field from long to string)? The Schema Registry checks the compatibility rules and rejects the change immediately before it can ever be sent to Kafka.

5. Summary: What We Learned

Sharing DTO libraries solves basic compiler errors, but it damages team autonomy and turns microservices into a distributed monolith.

By moving from Code-Level Contracts (Shared DTOs) to Data-Level Contracts (Apache Avro + Schema Registry):

• Teams can deploy their services whenever they want.
• Changes happen safely through controlled schema evolution.
• Payloads are smaller and faster because of binary format.

If your event-driven systems are slowing down because teams are constantly waiting for DTO updates, it is time to move to schema-based contracts and set your services free.

Why Sharing DTOs is a Trap: Moving from Tight Coupling to Apache Avro in Event-Driven Systems was originally published in ThreadSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is not a story about someone breaking a six-digit code. It is about a permission that can remain useful long after the task that justified it has finished.

I maintain Mac MCP, an open-source project that lets an AI assistant work with macOS applications and, with explicit setup, interact with another Mac. Building the cross-Mac flow made me think carefully about a simple question: what is the owner actually approving?

What the code proves

The receiving Mac creates a short-lived invitation. In the current implementation, the offer lives for up to 120 seconds. A request awaiting the owner’s decision has its own expiry window. The receiving Mac displays a six-digit check and asks its owner to accept or refuse the connection.

The important detail is that the asking machine cannot approve its own request. Both sides show the check. Someone physically or remotely controlling the receiving Mac must make the decision there.

That prevents a category of mistakes in which the agent requesting access also gets to authorize its own access. It does not make the connection permanently safe, and it does not tell the owner what a future automation might attempt.

The invitation is not the permission

On approval, the receiving Mac issues a separate credential. The requester stores it in an owner-only file. The receiver retains a hash rather than sharing its main API key. The permission can be restricted to status information, read-only operations, or fuller tool use, and the receiving Mac’s own safety profile still matters.

So far, so good. But look at the lifecycle of the objects.

The invitation expires, and so does a request awaiting approval. The resulting peer credential is revocable, but it follows different rules: full access already supports durations of one hour, the rest of today, or seven days, after which it falls back to read-only. Without a selected duration, access can persist until revoked. None of those choices is the same as an automatic grant scoped to a particular agent job. That distinction is easy to miss when the entire flow is summarized as “temporary pairing.”

A pairing can be temporary without the resulting access being temporary.

A user on Reddit put it more plainly: if they grant access for one job, why should that grant outlive the job? I think that is the right follow-up question.

The three clocks I want to separate

The first clock is for proving identity. A short-lived code helps ensure two intended machines are participating in the same ceremony. It should expire quickly, and retry attempts should be limited.

The second is for the working relationship between machines. Maybe these are both my Macs and I want them to stay paired for months. Having to repeat a pairing ritual for every status check would be a poor experience.

The third is for authority. Today the job needs to read a document from the other Mac. Tomorrow it might need to run a recipe. Next week it may have no business touching that machine at all. Those are separate decisions from whether the two devices still recognize each other.

I would rather keep a remembered device relationship and give it a narrow, expiring grant than force people to choose between permanent broad access and constant re-pairing.

What I would test before shipping that change

A permission-expiry feature sounds like a timestamp and an if statement. It needs more care than that.

I would test a grant that expires while the remote Mac is offline. I would test a job that begins before expiry but tries a consequential action afterward. I would test clock disagreements, restarts, a revoked token that is presented again, and a user who narrows access while an agent still has work in progress.

I would also separate status visibility from write access. Being able to see whether the other Mac is online should not require permission to edit files or submit forms. And the UI should show the owner exactly which device holds a grant, which actions it allows and how to revoke it.

There is a particularly nasty failure mode here: the caller caches a positive access decision, the receiver revokes the grant, and the next request still succeeds using the cached state. If the receiver is authoritative, permission needs to be checked where the action happens, not only when a pair is first accepted.

I have not shipped task-scoped expiring grants in this pairing flow. The feature remains a proposal, not something I can call protected by design today.

Why the distinction matters to AI agents

A human opening a file on their second Mac has a rough idea of when they are finished. An agent might return hours later, reuse an existing tool connection and continue from an old plan. Successful authentication at that point says very little about whether the owner still wants the original authority exercised.

Short pairing codes solve an entry problem. Narrow scopes and explicit approvals limit what can happen next. Revocation and expiry solve the permission-lifetime problem. I want each of those claims to stay separate so a green “paired” label never gets mistaken for “safe to do anything.”

For me, a good security interface doesn’t ask the user to remember which access they once granted. It gives them a clear answer to what is allowed now.

Project and implementation: https://github.com/bulutarkan/mac-mcp

Disclosure: AI assistance was used to draft and edit this article. The described current behavior was checked against the Mac MCP source; the time-limited access design is a proposal, not a shipped feature.

The Pairing Code Expired. The Machine Permission Didn’t. was originally published in ThreadSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.