Expected behaviour: Making an edit marked as "bot" with Wikibase REST API when the client does not authenticate as a user having a "bot" right should be rejected due to insufficient permissions.
Current behaviour. Making a bot edit as an anonymous user (who does not have "bot" right) succeeds - the edit is marked as done by bot and skipped in Recent Changes

Note: the Wikibase REST API isn’t enabled in production yet, no need to panic :)

curl -i -H 'Content-Type: application/json' --data '{"statement":{"type":"statement","mainsnak":{"snaktype":"value","property":"P62013","datavalue":{"type":"string","value":"abcde"}},"rank":"normal"},"bot":true}' https://wikidata.beta.wmflabs.org/w/rest.php/wikibase/v0/entities/items/Q81561/statements

Resulting edit:

That’s an anonymous edit (note the lack of authentication in the request) – it definitely shouldn’t be allowed to be listed as a bot edit in the recent changes (which means it won’t be shown by default in recent changes or watchlists). The bot flag in the request should be silently ignored, because the anonymous user doesn’t have the bot right (compare Special:UserGroupRights).

This happens because MediaWikiEditEntityFactoryItemUpdater::update() directly sets the EDIT_FORCE_BOT flag based on the edit metadata bot flag, which in turn directly comes from the request (in AddItemStatement::execute()).

		$status = $editEntity->attemptSave(
			$item,
			$this->summaryFormatter->format( $editMetadata->getSummary() ),
			EDIT_UPDATE | ( $editMetadata->isBot() ? EDIT_FORCE_BOT : 0 ), // <--
			false,
			false,
			$editMetadata->getTags()
		);

It’s missing an equivalent of this EntitySavingHelper::attemptSaveEntity() snippet somewhere in the chain (or maybe it should use the helper instead of the underlying EditEntity?):

		if ( isset( $requestParams['bot'] ) && $requestParams['bot'] &&
			$this->permissionManager->userHasRight( $user, 'bot' ) // <--
		) {
			$flags |= EDIT_FORCE_BOT;
		}