they do not think that the position should have full access to the environment. It is an "architecture" position and not a "sysadmin" position is how they explained it to me.
That seems reasonable for a moderately sized company with the infrastructure you describe. Your analogy of drawing a map without being able to visit the area is a very good indicator of the miscommunication occurring here - you need to be able to see all the infrastructure, but you're asking for full access. To use an imperfect car analogy (this is Slashdot after all), you need to be able to lift the hood and see the engine. That's reasonable. You're asking for full access to change all parts of the car. That's overkill, actually implementing changes is outside the scope of your responsibilities.
A requirement of any senior role is the ability to delegate responsibilities and trust the input from your team and other managers. I suggest that as an architect you should be asking the IT core team for the network maps, system configuration lists, etc that you need as inputs for your design decisions. You can then respond with changes that are needed to their systems. In your new role you would have the authority that your changes are requirements not suggestions. However the responsibility to make those changes still rests with the IT core team - you don't need and should not have access to make those changes yourself.
I like to think of architect roles as consultants with authority. You give them the best documentation you have, and maybe read access to the systems. They come back with recommendations for changes, while architects have the authority to state them as requirements instead of just recommendations. But just like you wouldn't give an external consultant full admin to your systems (eg: domain controllers or databases), you wouldn't give it to an architect.