In the vast majority of cases where these phrases are used, agile has mistakingly been used to mean that the development process in use is ad hoc or even non-existant. It's not hard to get to the bottom of what people mean by agile, particularly in interviews, with a few simple questions.
(Simon Brown in Agile or ad hoc?)

That's certainly correct. I'd like to add that agile development requires a team of truly senior developers who have experience with all the tools they need to use. And you need to have a management that accepts let you do your thing during a Scrum sprint.

From what I can see is that you slide into ad hoc development when you did not plan well or can't plan, e.g. due to lack of a specification. So the only solution you have is to start and try. It's probably not in compliance with pure agile development, but while your customer or your management trusts you, go along and create the missing spec on the way. A little bit down the road you will have an opportunity to implement a more formal - aehm I mean agile - process.

What I'm saying is that Scrum sprints require you to plan. And if you don't know what to plan, because you are not sure what you should create, because you lack domain knowledge and there is no product owner or on-site customer available, then you will have to substitute that with your own creativity and imagination.

In the end I believe that's still agile development.

Update: It's very important that you record everything you learn during the ad hoc phase. It's not so much development what you do during that phase. It's more research and experimentation while building some prototype(s) along the way.

At the end of the day though, i find that the best way to get them to do what you want, is to make them feel like it was their idea in the first place. That's probably the most valuable trick to learn. I know that seems like we lose the credit for the catch but we're engineers right? We usually don't get recognition unless something goes terribly wrong:)

(Rick Marry in a comment to How do you get open source frameworks past the red tape? )

That's very well said. It is indeed the most valuable trick you can learn in order to prevail in many situations in the corporate world. Although some developers or engineers might want to disagree at some point we all are sales people as well. Probably as a true consultant you are more a sales person for ideas than you are an engineer. So your people skills and your ability to circumvent blockades is a key element for doing your job well.