scheme@(guile-user)> (define alst '(("a" . 1) ("b" . 2)))
scheme@(guile-user)> (set-cdr! (assoc "a" alst) 5)
scheme@(guile-user)> (assoc "a" alst)
$1 = ("a" . 5)

scheme@(guile-user)> (assoc-set! alst "a" 6)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure set-cdr!: Wrong type argument in position 1 (expecting mutable pair): ("a" . 5)

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

Mutation may allow a sandboxed evaluation to break some invariant in users of data supplied to it. A lot of code culturally doesn’t expect mutation, but if you hand mutable data to a sandboxed evaluation and you also grant mutating capabilities to that evaluation, then the sandboxed code may indeed mutate that data. The default set of bindings to the sandbox do not include any mutating primitives.

Relatedly, set! may allow a sandbox to mutate a primitive, invalidating many system-wide invariants. Guile is currently quite permissive when it comes to imported bindings and mutability. Although set! to a module-local or lexically bound variable would be fine, we don’t currently have an easy way to disallow set! to an imported binding, so currently no binding set includes set!.