Who owns the commit when an AI assistant can write to a vault?
Assistants may prepare durable changes, but review, confirmation, commit, and rollback become the trust boundary once storage can mutate.
Assistants may prepare durable changes, but review, confirmation, commit, and rollback become the trust boundary once storage can mutate.
Who owns the commit when an AI assistant can write to a vault?
The boundary
Who is accountable if an AI-assisted note system can quietly mutate the user vault? The problem is not that the model writes text. The problem is that durable storage changed without a visible owner.
Suggestion and commit are different responsibilities. Collapsing them makes the system feel smooth while making trust harder.
The artifact
The serverless vault bridge keeps the assistant in the proposal lane. It can prepare a diff, but the final write requires exact-content confirmation, digest binding, path safety, expected base SHA, and conflict handling.
That adds friction on purpose. The friction is the point where ownership becomes visible again.
What I would reuse
The pattern is not limited to Markdown vaults. Any AI workflow that writes into durable systems should separate suggested change, reviewed change, committed change, and rollback story.
Inspect the repository
https://github.com/89325516/serverless-vault-bridge