Knowledge · Architecture

    Human Actors vs Machine Actors

    When AI agents, webhooks and scheduled jobs write to your records, 'who did this' stops being obvious. How to model machine actors without losing accountability.

    How should a system record actions taken by AI or automation?

    Every write should record what kind of actor performed it, which specific actor it was, and — for agents acting on someone's behalf — which human authorized the session. Automation without an actor model produces records that changed with no accountable party, which is indistinguishable from an unexplained change.

    Key takeaways

    • Machine actors need identity, not anonymity.
    • An agent acting for a person carries both identities, not one.
    • Provider callbacks and scheduled jobs have no authorizing human, and must not invent one.
    • Actor type is a required field, not an optional annotation.
    • Without an actor model, automation and intrusion look the same in the log.

    The kinds of actor a real system has

    • A person, acting directly in the interface.
    • An agent, acting inside a session a person authorized.
    • A background process, running on a schedule with no human present.
    • A provider callback, triggered by an external system's event.

    Why fabricating a human is worse than admitting there isn't one

    It is tempting to attribute an automated write to the account that configured the automation, because it makes the record look tidy. It also makes the log lie. If nobody authorized this particular write, the honest record has an empty authorizing person and a clearly named machine actor — which is the record you need when you are trying to work out why something changed at three in the morning.

    Machine actors do not get extra rights

    An agent operating on a person's behalf should be bounded by both the permissions the underlying integration grants and the permissions the authorizing person holds. The narrower of the two wins. An automation that can do more than the person who started it is a privilege escalation with a friendly name.

    Where URBLD fits

    URBLD's tenant and actor invariant requires every write to carry an actor type drawn from a fixed set — person, assistant, receptionist, scheduler, follow-ups, machine protocol client, a named provider webhook, or system — together with a stable actor identifier. Agent-initiated writes must carry the authorizing person; webhook and system writes carry none rather than a fabricated one. Agent authority is the intersection of the integration's granted scopes and the authorizing person's role.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Architecture

    How information should move through a business.

    Browse Architecture
    Share this page