this is actually against principles. Your aggregate should only maintain state that it requires itself to decide what it should do on incoming commands. It may accidentally be that this is also state that the Saga required. In that case, I would recommend implementing that state inside the Saga, too. Reading from your aggregate gives you coupling between the Saga and the aggregate (tying them to the same service) and forces the Aggregate to be able to expose this state.
Alternatively, you could consider extracting certain logic to services/entities/value objects so that both your aggregate as well as the Saga can use it.
I hope this helps.