🔄 Topic

Extending the supervised-agent workflow with an artifact-delivery design that limits access to one intended file and verifies the content before it reaches a recipient.

🎯 Goal

Make it possible to deliver a completed task artifact without exposing a broader storage area, trusting an unverified file, or sending duplicate messages when recovery logic runs.

🛠 What I Did

I added a delivery model where one opaque token maps to exactly one artifact. Links expire after seven days and can be revoked. The durable record stores a SHA-256 hash of the token rather than the token itself.

The artifact is recorded with its size and SHA-256 digest. When the delivery path serves it, the bytes are re-hashed; a changed file fails closed instead of being delivered as though it were the original result.

The delivery path has deliberately narrow reach: it can serve the linked artifact, not logs, backups, or arbitrary filesystem paths. A Telegram-style file delivery is allowed only after the task is completed, its result contract is sealed, the size limit passes, the hash matches, and the destination is confirmed.

Verification covered the uncomfortable cases, not just the happy path:

  • a fresh process retrieved byte-identical content from a valid link
  • forged, expired, and revoked links were rejected
  • link expiry did not delete the underlying artifact
  • repeat and simulated-crash delivery attempts did not produce duplicate file messages
  • the full suite passed 219 tests after the phase

The feature remained flag-gated and fixture-only; no production listener or live channel was changed by this implementation phase.

🔗 Key Cybersecurity Connections

The design is a compact example of several security controls working together:

  • authorization: a recipient gets access to one object, not a file browser
  • integrity: SHA-256 checks make tampering detectable between recording and delivery
  • confidentiality: narrow routes and opaque tokens reduce accidental disclosure
  • accountability: access and delivery state are durable evidence
  • availability: recovery distinguishes an attempt from a confirmed delivery

🔍 Investigation Questions

  • Does this token resolve to one artifact and nothing else?
  • Was the token stored safely, or was a reusable secret written into logs?
  • Did the served bytes still match the recorded digest?
  • Was the recipient actually confirmed, or did the sender only attempt delivery?
  • Does expiry revoke access without destroying evidence needed for an audit?

🚨 Detection Opportunities

  • a token resolving to more than one artifact
  • an artifact hash changing after it was recorded
  • repeated failed access against the same revoked link
  • a delivery retry without a destination-inspection record
  • a completed task attempting to send a file above the permitted limit

🧭 MITRE ATT&CK Techniques

No direct MITRE ATT&CK mapping claimed. This is secure object delivery, authorization, and integrity design.

🗺 Visual Investigation Diagram

Completed task records artifact
    ↓
Narrow, expiring link is created
    ↓
Link and artifact integrity are checked
    ↓
Recipient delivery is confirmed once
    ↓
Recovery inspects before retrying

⚠ Challenges

It was easy to focus only on the link and forget the file itself. A valid link is not enough when the bytes it serves could have changed after the artifact was registered.

📚 What I Learned

“Send a file” sounds like a small feature until the security questions are written down. Scope, expiry, revocation, integrity, destination confirmation, and duplicate-safe recovery are the difference between a convenient shortcut and an accountable delivery control.

➡ Next Steps

  • Add access-rate signals for revoked and expired links
  • Exercise the size limit with boundary-value fixtures
  • Review how long delivery metadata should be retained
  • Keep link scope narrow as new artifact types are added

🧠 Reflection

The safest sharing mechanism is often the least ambitious one. Giving access to one known object for a limited time is easier to explain, verify, and revoke than opening a general-purpose storage path.

🧩 Lessons Learned

What worked

Treating delivery as a stateful process with pre-send and post-send checks.

What broke

Early thinking reduced the problem to generating a download URL.

Why it broke

The URL alone did not prove that the file was unchanged or that a retry would be safe.

Fix / takeaway

Bind access to one artifact, verify the bytes at use time, and inspect destination state before retrying delivery.

📈 Skill Progression Context

This work strengthens practical understanding of authorization, hashing, secure design, and operational evidence. Those are useful across application security, SOC investigations, and secure automation work.

😄 TL;DR

Made file delivery narrow, time-limited, hash-checked, and safe to recover without sending the same result twice.