Agile is defined by the values and principles laid out in the Manifesto for Agile Software Development. There's no such thing as "an Agile methodology". When the Manifesto was created, it was an abstraction layer over a number of methods, including Scrum, Extreme Programming, DSDM, Crystal, and Adaptive Software Development, to name a few. The Manifesto was the common ground between these various methodologies.
Very few practices are mandated as part of the Manifesto. In fact, there is only one: continuous improvement of the way of working. The other values and principles can help a team choose or develop practices, but there aren't any practices mandated in order to be agile. Different frameworks may require certain practices or put rules on structure beyond those in the Manifesto, but those are requirements of the framework and not Agile.
Looking at the three things identified in the question ("90 minute Scrums", "rigid processes", and "ban on any communication beyond 'Done, Next, Blocker'"), only two are inherently against the values and principles laid out in the Manifesto - the rigid processes and restricted communication.
One of the values of Agile Software Development is "individuals and interactions over processes and tools". The last principle involves reflecting on and improving the processes used by the team. If the emphasis is on the processes and they are rigid enough to not allow for continuous improvement, I would consider that to be inconsistent with Agile Software Development.
Limited communication also goes against the value of "individuals and interactions over processes and tools", but a number of underlying principles such as stakeholders working together throughout the effort and self-organizing teams. Communication is a cornerstone of collaboration, information sharing, organization, and even trust.
Long Daily Scrums or stand-ups aren't against any of the values and principles of Agile Software Development, but they do go against the rules of Scrum (if you are choosing to use Scrum as your framework). In fact, if the team is choosing to have them, one could make an argument that it's a side-effect of self-organizing teams. However, it does depend on the context and there is probably a better way of working that can reduce the time in the meetings and increase the time that the team spends on delivering a working product.